RFC 1561
Use of ISO CLNP in TUBA Environments
📜 RFC 1561: Use of ISO CLNP in TUBA Environments 🎀
Okay bestie, here's the deal with this one. It's written by D. Piscitello from Core Competence ✨, it's dated December 1993, and it's filed under the Network Working Group 🌸. Its category is Experimental 🧪. The title block doesn't list anything it obsoletes or updates, so it's a fresh start, no drama 💅.
Status of This Memo ✨
So this memo defines an Experimental Protocol for the Internet community 🧪. It is NOT an Internet standard of any kind, just so we're clear 🙅♀️. The authors are literally asking for discussion and suggestions for how to make it better 💖. And distribution of this memo is unlimited, so share it with everyone 🌍.
Abstract 📝
This memo is a profile of the ISO/IEC 8473 Connectionless-mode Network Layer Protocol (CLNP, [1]) 🦋. It's meant to be used together with RFC 1347, TCP/UDP over Bigger Addresses (TUBA, [2]) 👑. The whole point is that CLNP gives TCP (Transmission Control Protocol, [3]) and UDP (User Datagram Protocol, [4]) the lower-level service they expect 🫶. CLNP basically gives you the same datagram service as the Internet Protocol (IP, [5]), but it also lets you carry bigger network addresses, and those addresses have extra structure to help with routing 🗺️✨.
The protocols are super similar but not identical, so this document is about keeping the meaning of IP information that CLNP doesn't have, while still keeping things consistent between Internet and OSI environments 🧩. Honestly this is a big win because it lets people make the most of CLNP implementations that are already out there 🙌.
Acknowledgments 🫶
Huge thanks to Ross Callon (Wellfleet Communications), John Curran (BBN), Cyndi Jung (3Com), Paul Brooks (UNSW), Brian Carpenter (CERN), Keith Sklower (Cal Berkeley), Dino Farinacci and Dave Katz (Cisco Systems), Rich Colella (NIST/CSL) and David Oran (DEC) for helping put this text together 💜. The legends! 😭
Conventions 💅
Here's how the language in the specification items works, so read this part carefully 👀:
- MUST, SHALL, or MANDATORY -- the item is an absolute requirement of the specification. No wiggle room 🔥.
- SHOULD or RECOMMENDED -- the item should generally be followed for all but exceptional circumstances. Follow it unless there's a really good reason not to 🍓.
- MAY or OPTIONAL -- the item is truly optional and may be followed or ignored according to the needs of the implementor. Your call, babe 🦋.
1. Terminology 📖
To the extent possible, this document is written in the language of the Internet ✨. So it says "packet" instead of "protocol data unit", and "fragment" instead of "segment" 🧩. A few terms come over from OSI, and they're mostly kept so that you can cross-reference this document with RFC 994 [6] or ISO/IEC 8473 without wanting to scream 🙈. Most OSI acronyms are avoided on purpose, so you're welcome 💖.
2. Introduction 🌸
The goal here is to let compatible and interoperable implementations wrap TCP and UDP packets inside CLNP data units 🎁. Honestly, it's less of a protocol spec and more of a "hosts requirements" document for the network layer of TUBA implementations 🧚. It assumes you already know STD 5, RFC 791, STD 5, RFC 792 [7], STD 3, RFC 1122 [8], and, to a lesser extent, RFC 994 and ISO/IEC 8473 📚. This document is compatible with ISO/IEC 8473 (although it's more restrictive than that standard) 💅. Specifically, the order, semantics, and processing of CLNP header fields are consistent between this document and ISO/IEC 8473 💯.
[Note: RFC 994 contains the Draft International Standard version of ISO CLNP, in ASCII text. This is not the final version of the ISO/IEC protocol specification; however, it should provide sufficient background for the purpose of understanding the relationship of CLNP to IP, and the means whereby IP information is to be encoded in CLNP header fields. Postscript versions of ISO CLNP and associated routing protocols are available via anonymous FTP frommerit.edu, and may be found in the directory/pub/ISO/IEC.]
3. Overview of CLNP 🦋
ISO CLNP is a datagram network protocol 📦. It gives the transport layer fundamentally the same underlying service that IP does 🤝. CLNP offers essentially the same maximum datagram size ✨. And when datagrams need to cross a network whose maximum packet size is smaller than the datagram, CLNP has fragmentation mechanisms for that: data unit identification, fragment/total length, and offset 🧩. Just like IP, a checksum computed on the CLNP header checks that the information used to process the CLNP datagram was transmitted correctly 🔍. There's also a lifetime control mechanism, "Time to Live", which limits how long a datagram is allowed to stick around in the internet system ⏳. And, same as IP, there's a set of options for control functions that are needed or useful in some situations but not for the most common communications 🎀.
Here's the tea ☕: the encoding of options is different between the two protocols, and so is the way higher level protocols get identified 🫣. CLNP and IP also represent header and fragment lengths differently, and CLNP's lifetime control (time-to-live) has finer granularity 🔬.
Some of these differences aren't really "issues", since CLNP lets certain options be specified and encoded in flexible ways. This means you can use and encode certain IP options without changing the syntax 🦋. Others, like higher level protocol identification and timestamp, have to be handled transparently in this profile so TCP and UDP work correctly, and so OSI implementations still interoperate 🫶. Section 4 describes how the header fields of CLNP must be populated to meet the needs of TCP and UDP 📋.
Errors detected while processing a CLNP datagram MAY be reported using CLNP Error Reports 🚨. Implementations of CLNP for TUBA environments MUST be capable of processing Error Reports 💯. This matches the 1992 edition (2) of the ISO/IEC 8473 standard 📚. Control messages, like echo request/reply and redirect, are handled similarly in CLNP, meaning they're identified as separate network layer packet types 🧾. The relationship between CLNP Error and Control messages and the Internet Control Message Protocol (ICMP, [7]), along with the issues about handling these messages, is covered in Section 5 🌈.
Table 1 gives you the high-level comparison of CLNP to IP 👀:
Function | ISO CLNP | DOD IP
----------------------|------------------------|-----------------------
Header Length | indicated in octets | in 32-bit words
Version Identifier | 1 octet | 4 bits
Lifetime (TTL) | 500 msec units | 1 sec units
Flags | Fragmentation allowed, | Don't Fragment,
| More Fragments | More Fragments,
| Suppress Error Reports | <not defined>
Packet Type | 5 bits | <not defined>
Fragment Length | 16 bits, in octets | 16 bits, in octets
Header Checksum | 16-bit (Fletcher) | 16-bit
Total Length | 16 bits, in octets | <not defined>
Addressing | Variable length | 32-bit fixed
Data Unit Identifier | 16 bits | 16 bits
Fragment offset | 16 bits, in octets | 13 bits, 8-octet units
Higher Layer Protocol | Selector in address | Protocol
Options | Security | Security
| Priority | TOS Precedence bits
| Complete Source Route | Strict Source Route
| Quality of Service | Type of Service
| Partial Source Route | Loose Source Route
| Record Route | Record Route
| Padding | Padding
| <defined herein> | Timestamp
Table 1. Comparison of IP to CLNPThe composition and processing of a TCP pseudo-header, for when CLNP is providing the lower-level service that TCP and UDP expect, is described in Section 6 🧠.
[Note: This experimental RFC does not discuss multicasting. Presently, there are proposals for multicast extensions for CLNP in ISO/IEC/JTC1/SC6, and a parallel effort within TUBA. A future revision to this RFC will incorporate any extensions to CLNP that may be introduced as a result of the adoption of one of these alternatives.] 🌸
4. Proposed Internet Header using CLNP ✨
okay bestie, this is where it gets spicy 🌶️ Here's the CLNP header as it's proposed for TUBA environments, drawn out so you can see every single bit 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........Data Link Header........ | NLP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Header Length | Version | Lifetime (TTL)|Flags| Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest Addr Len | Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROTO field | Src Addr Len | Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Source Address | Reserved | Data Unit Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Offset | Total Length of packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (see Table 1) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note that each tick mark represents one bit position 🔍
Figure 4-1. CLNP for TUBA
Note 1: For illustrative purposes, Figure 4-1 shows Destination and Source Addresses having a length of 19 octets, including the PROTO/reserved field. In general, addresses can be variable length, up to a maximum of 20 octets, including the PROTO/reserved field. Note 2: Due to differences in link layer protocols, it is not possible to ensure that the packet starts on an even alignment. Note, however, that many link level protocols over which CLNP is operated use a odd length link (e.g., IEEE 802.2). (In Figure 4-1, the rest of the CLNP packet is even-aligned.) 🫶
Okay so now the fun part: here's how every CLNP field gets encoded for TUBA environments 🎀
4.1. Network Layer Protocol Identification (NLP ID)
This one-octet field is how you know this is the ISO/IEC 8473 protocol 🦋 It MUST set to binary 1000 0001.
4.2. Header Length Indication (Header Length)
Header Length is the length of the CLNP header in octets, so it points you right to where the data begins 🧚 The value 255 is reserved 🚫 The header length is the same for all fragments of the same (original) CLNP packet 🧩
4.3. Version
This one-octet field tells you which version of the protocol this is. It MUST be set to a binary value 0000 0001 💖
4.4. Lifetime (TTL)
Like the TTL field of IP, this field shows the maximum time the datagram is allowed to stick around in the internet system ⏳ If this field has the value zero, then the datagram MUST be destroyed. A host, though, MUST NOT send a datagram with a lifetime value of zero 🙅♀️ This field gets modified during internet header processing. The time is measured in units of 500 milliseconds, but every module that processes a datagram MUST decrease the TTL by at least one, even if it handles the datagram in under 500 milliseconds. So you've gotta think of the TTL as just an upper bound on how long a datagram can exist ⏰ The whole point is to get undeliverable datagrams thrown away and to put a cap on the maximum CLNP datagram lifetime 🗑️ [Like IP, folks casually use TTL in CLNP as a rough hop count, which is so relatable 😭] Unless otherwise directed, a host SHOULD use a value of 255 as the initial lifetime value 🌈
4.5. Flags
Three flags are defined. They live in bits 0, 1, and 2 of the Flags/Type octet 🎀
0 1 2
+---+---+---+
| F | M | E |
| P | F | R |
+---+---+---+The Fragmentation Permitted (FP) flag, when set to a value of one (1), is semantically equivalent to the "may fragment" value of the Don't Fragment field of IP. Similarly, when set to zero (0), the Fragmentation Permitted flag is semantically equivalent to the "Don't Fragment" value of the Don't Fragment Flag of IP 🦋
[Note: If the Fragmentation Permitted field is set to the value 0, then the Data Unit Identifier, Fragment Offset, and Total Length fields are not present. This denotes a single fragment datagram. In such datagrams, the Fragment Length field contains the total length of the datagram.]
The More Fragments flag of CLNP is semantically and syntactically the same as the More Fragments flag of IP 🫶 A value of one (1) means more segments/fragments are coming. A value of zero (0) means the last octet of the original packet is in this segment 🏁
The Error Report (ER) flag is used to suppress the generation of an error message by a host/router that detects an error while processing a CLNP datagram. A value of one (1) means the host that originated this datagram thinks error reports are useful, and would dearly love to receive one if a host/router finds it necessary to discard its datagram(s) 🥺💜
4.6. Type field
The type field tells apart data CLNP packets, Error Reports, and Echo packets 👑 Here are the values of the type field that apply:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| flags | 1 | 1 | 1 | 0 | 0 | => Encoding of Type = data packet
+---+---+---+---+---+---+---+---+
| flags | 0 | 0 | 0 | 0 | 1 | => Encoding of Type = error report
+---+---+---+---+---+---+---+---+
| flags | 1 | 1 | 1 | 1 | 0 | => Encoding of Type = echo request
+---+---+---+---+---+---+---+---+
| flags | 1 | 1 | 1 | 1 | 1 | => Encoding of Type = echo reply
+---+---+---+---+---+---+---+---+Error Report packets get their own spotlight in Section 5 ✨ Echo packets and how they're used are described in RFC 1139 [9] 🧁
4.7. Fragment Length
Like the Total Length of the IP header, the Fragment Length field holds the length in octets of the fragment (i.e., this datagram), including both header and data 📦
[Note: CLNP also may also have a Total Length field, that contains the length of the original datagram; i.e., the sum of the length of the CLNP header plus the length of the data submitted by the higher level protocol, e.g., TCP or UDP. See Section 4.12.]
4.8. Checksum
A checksum is computed on the header only 🧮 It MUST be verified at each host/router that processes the packet. If header fields get changed during processing (e.g., the Lifetime), the checksum is modified too 🔄 If the checksum isn't used, this field MUST be coded with a value of zero (0). See Appendix A for the algorithms used in computing and adjusting the checksum 📜 Readers are encouraged to see [10] for a description of an efficient implementation of the checksum algorithm 🔥
4.9. Addressing
CLNP uses OSI network service access point addresses (NSAPAs) 🗺️ NSAPAs do the same identification and location jobs as an IP address, plus the protocol selector value that's encoded in the IPv4 datagram header, with extra hierarchy on top 🌸 General purpose CLNP implementations MUST handle NSAP addresses of variable length, up to 20 octets, as defined in ISO/IEC 8348 [11]. TUBA implementations, especially routers, MUST accommodate these as well. So for compatibility and interoperability with OSI use of CLNP, the initial octet of the Destination Address is assumed to be an Authority and Format Indicator, as defined in ISO/IEC 8348. NSAP addresses may be between 8 and 20 octets long (inclusive) 💅
TUBA implementations MUST support both ANSI and GOSIP style addresses. These are described in RFC 1237 [12] and illustrated in Figure 4-2 🫧 RFC 1237 covers the ANSI/GOSIP initial domain parts, plus the format and composition of the domain specific part. It's further recommended that TUBA implementations support the assignment of system identifiers for TUBA/CLNP hosts defined in [13], for host address autoconfiguration as described in [14] 🤖 Additional considerations about how the selector part gets interpreted and encoded are described in sections 4.9.2 and 4.9.4 🧠
+-------------+
| <-- IDP --> |
+----+--------+----------------------------------+
|AFI | IDI | <-- DSP --> |
+----+--------+----+---+-----+----+-----+---+----+
| 47 | 0005 |DFI |AA |Rsvd | RD |Area |ID |Sel |
+----+--------+----+---+-----+----+-----+---+----+
octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 |
+----+--------+----+---+-----+----+-----+---+----+Figure 4-2 (a): GOSIP Version 2 NSAP structure.
+-------------+
|<-- IDP --> |
+----+--------+----------------------------------+
|AFI | IDI | <-- DSP --> |
+----+--------+----+---+-----+----+-----+---+----+
| 39 | 840 |DFI |ORG|Rsvd | RD |Area |ID |Sel |
+----+--------+----+---+-----+----+-----+---+----+
octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 |
+----+--------+----+---+-----+----+-----+---+----+Figure 4-2 (b): ANSI NSAP address format for DCC=840
Here's the glossary for those layouts 📖
Definitions:
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
DFI DSP Format Identifier
AA Administration Authority
ORG Organization Name (numeric form)
Rsvd Reserved
RD Routing Domain Identifier
Area Area Identifier
ID System Identifier
Sel NSAP Selector4.9.1. Destination Address Length Indicator
This field tells you how long the Destination Address is, in octets 📏🎀
4.9.2. Destination Address 💖
Okay so this field holds an OSI NSAP address, the same kind we just covered in Section 4.9 🗺️. It MUST always contain the address of the final destination 🎯. (This is true even for packets with a source route option, see Section 4.13.4. Even with a source route, the destination is still the destination 🙈.)
The final octet of the destination address MUST always contain the value of the PROTO field, as defined in IP 🧁. The 8-bit PROTO field tells you which next level protocol is being used in the data portion of the CLNP datagram ✨. The values for the various protocols are specified in "Assigned Numbers" [15]. For the PROTO field, the value of zero (0) is reserved 🙈.
TUBA implementations that support TCP/UDP as well as OSI MUST use the protocol value (1Dh, Internet decimal 29) that's reserved for ISO transport protocol class 4 👑.
4.9.3. Source Address Length Indicator 🧮
This field tells you the length, in octets, of the Source Address.
4.9.4. Source Address 🫶
Same energy as the destination, bestie: this field holds an OSI NSAP address, as described in Section 4.9.
The final octet of the source address is reserved 🔒. It MAY be set to the protocol field value on transmission, and shall be ignored on reception (the value of zero MUST not be used) 🙅♀️.
4.10. Data Unit Identifier 🪪
Like the Identification field of IP, this 16-bit field is used to tell apart the segments of the same (original) packet so they can be put back together during reassembly 🧩. This field is present when the fragmentation permitted flag is set to one.
4.11. Fragment Offset 📍
Like the Fragment Offset of IP, this 16-bit field tells you the relative octet position of the data in this fragment, measured from the start of the data submitted to CLNP. Basically, it says where in the original datagram this fragment belongs 🧭. The offset is measured in octets, and the value of this field shall always be a multiple of eight (8) 🍓. This field is present when the fragmentation permitted flag is set to one.
4.12. Total Length 📏
The total length of the CLNP packet in octets is determined by the originator and placed in the Total Length field of the header 💅. The Total Length field specifies the entire length of the original datagram, including both the header and the data. This field MUST NOT be changed in any fragment of the original packet for the duration of the packet lifetime ⏳. This field is present when the fragmentation permitted flag is set to one.
4.13. Options 🎀
Every CLNP option is a "triplet" of the form <parameter code>, <parameter length>, and <parameter value> 💜. Both the parameter code and the length fields are always one octet long. The length of the parameter value, in octets, is indicated in the parameter length field. The following options are defined for CLNP for TUBA ✨.
4.13.1. Security 🔐
The value of the parameter code field is binary 1100 0101. The length field MUST be set to the length of a Basic (and Extended) Security IP option(s) as identified in RFC 1108 [16], plus 1. Octet 1 of the security parameter value field (the CLNP Security Format Code) is set to binary 0100 0000. That tells you the remaining octets of the security field contain either the Basic option, or the Basic and Extended options, as identified in RFC 1108 🛡️. This encoding points to the administration of the source address (e.g., ISOC) as the administration of the security option. So it's distinguished from the globally unique format, whose definition is reserved for OSI use 🌈. Implementations wishing to use a security option MUST examine the PROTO field in the source address. If the value of PROTO indicates the CLNP client is TCP or UDP, the security option described in RFC 1108 is used 💀.
[Note: If IP options change, TUBA implementations MUST follow the new recommendations. This RFC, or revisions thereof, must document the new recommendations to assure compatibility.]
The formats of the Security option, encoded as a CLNP option, are as follows. The CLNP option will be used to convey the Basic and Extended Security options as sub-options. What that means is the exact encoding of the Basic/Extended Security IP Option is carried in a single CLNP Security Option, and the length of the CLNP Security option reflects the sum of the lengths of the Basic and Extended Security IP Option 🧠.
+--------+--------+--------+--------+--------+---//----+-
|11000100|XXXXXXXX|01000000|10000010|YYYYYYYY| | ...
+--------+--------+--------+--------+--------+---//----+----
CLNP CLNP CLNP BASIC BASIC BASIC
OPTION OPTION FORMAT SECURITY OPTION OPTION
TYPE LENGTH CODE TYPE LENGTH VALUE
(197) (130)
---+------------+------------+----//-------+
... | 10000101 | 000LLLLL | |
-----+------------+------------+----//-------+
EXTENDED EXTENDED EXTENDED OPTION
OPTION OPTION VALUE
TYPE (133) LENGTHThe syntax, semantics and processing of the Basic and Extended IP Security Options are defined in RFC 1108 📖.
4.13.2. Type of Service 🚦
[Note: Early drafts recommended the use of IP Type of Service as specified in RFC 1349. There now appears to be a broad consensus that this encoding is insufficient, and there is renewed interest in exploring the utility of the "congestion experienced" flag available in the CLNP QOS Maintenance option. This RFC thus recommends the use of the QOS Maintenance option native to CLNP.]
The Quality of Service Maintenance option lets the originator of a CLNP datagram share info about the quality of service requested by the originating upper layer process 📣. Routers MAY use this information as an aid in selecting a route when more than one route satisfies the other routing criteria and the available routes are known to differ with respect to these qualities of service: ability to preserve sequence, transit delay, cost, and residual error probability 🛣️. Through this option, a router can also indicate that it is experiencing congestion 🚧.
The encoding of this option is as follows 👀:
+-----------+-----------+----------+
| 1100 0011 | 0000 0001 | 110ABCDE |
+-----------+-----------+----------+
CLNP QOS OPTION QOS FLAGS
TYPE (195) LENGTHThe value of the parameter code field MUST be set to binary 1100 0011 (the CLNP Quality of Service Option Code point). The length field MUST be set to one (1) 🔢.
Bits 8-6 MUST be set as indicated in the figure. The flags "ABCDE" are interpreted as follows 💅:
A=1 choose path that maintains sequence over
one that minimizes transit delay
A=0 choose path that minimizes transit delay over
one that maintains sequence
B=1 congestion experienced
B=0 no congestion to report
C=1 choose path that minimizes transit delay over
over low cost
C=0 choose low cost over path that
minimizes transit delay
D=1 choose pathe with low residual error probability over
one that minimizes transit delay
D=0 choose path that minimizes transit delay over
one with low residual error probability
E=1 choose path with low residual error probability over
low cost
E=0 choose path with low cost over one with low
residual error probability4.13.3. Padding 🧸
The padding field is used to lengthen the packet header to a convenient size 🎀. The parameter code field MUST be set to binary 1100 1100. The value of the parameter length field is variable. The parameter value MAY contain any value, and the contents of padding fields MUST be ignored by the receiver 🙉.
+----------+----------+-----------+
| 11001100 | LLLLLLLL | VVVV VVVV |
+----------+----------+-----------+4.13.4. Source Routing 🗺️
Like the strict source route option of IP, the Complete Source Route option of CLNP is used to specify the exact and entire route an internet datagram MUST take 🛤️. The Partial Source Route option of CLNP is the equivalent of the loose source route option of IP. It's a way for the source of an internet datagram to supply (some) routing information that gateways use while forwarding the datagram toward its destination 💫. The identifiers in this option are network entity titles. They're semantically and syntactically the same as NSAPAs, and they can be used to unambiguously identify a network entity in an intermediate system (router) 🪄.
The parameter code for Source Routing is binary 1100 1000. The length of the source routing parameter value is variable.
The first octet of the parameter value is a type code. It indicates either Complete Source Routing (binary 0000 0001) or Partial Source Routing (binary 0000 0000) 🧭. The second octet identifies the offset of the next network entity title to be processed in the list, relative to the start of the parameter. For example, a value of 3 identifies the first address in the list. That offset gets modified by each router using a complete source route, or by each listed router using a partial source route, so it points to the next NET 👉.
The third octet begins the list of network entity titles. Only the NETs of intermediate systems are included in the list. The source and destination addresses shall not be included. The list is made of variable length network entity title entries, and the first octet of each entry gives the length of the network entity title that makes up the rest of the entry 📜.
4.13.5 Record Route 🗺️
okay so the Record Route option is basically the CLNP version of the IP record route option, and its whole job is tracing the path a CLNP datagram takes 🦋 as it travels toward its final destination. the recorded route is a list of network entity titles (see Source Routing), and each one gets added as the datagram is forwarded along the way ✨
here's the iconic part: only the titles of intermediate systems (routers) that actually processed the datagram get recorded 💅 the originator's network entity title SHALL NOT be recorded in the list. so the sender never adds itself 🙈
The parameter code for Record Route is 1100 1011 in binary 🔢. the length of the parameter value is variable.
the first octet of the parameter value is a type code 🎀 it's either:
- Complete Recording of Route (
0000 0001) - Partial Recording of Route (
0000 0000)
when complete recording is selected, reassembly at intermediate systems MAY be performed only when all fragments of a given datagram followed the same route 🧩 partial recording of route is the one that "loosens" that constraint, so it's giving flexibility 🌈
the second octet is the offset where the next network entity title entry MAY be recorded. this is the end of the current list, measured relative to the start of the parameter 🦋 the initial recording position is identified by a value of 3.
here's how a router records its entry, step by step 🧚
- it adds the length of its network entity title entry to the value of the record route offset.
- it compares that new value to the record route list length indicator.
- if the value does not exceed the length of the list, the entity title entry is recorded, and the offset value goes up by the length of that entry 💖
- otherwise, recording of the route is terminated, and the router MUST not record its network entity title in the option 💀
if recording of the route has been terminated, this (second) octet has a value of 255. rip to the list being full 😭
the third octet begins the list of network entity titles 🫶
4.13.6 Timestamp ⏰
[Note: There is no timestamp option in edition 1 of ISO/IEC 8473, but the option has been proposed and submitted to ISO/IEC JTC1/SC6.]
the parameter code value 1110 1110 is used to identify the Timestamp option, and its syntax and semantics are identical to the ones defined in IP ✨
The Timestamp Option is defined in STD 5, RFC 791. the CLNP parameter code 1110 1110 gets used instead of the option type code 68 to identify the Timestamp option, and the parameter value carries the option length 🍓 here's the breakdown:
- octet 1 of the Timestamp parameter value shall be encoded as the pointer (octet 3 of IP Timestamp)
- octet 2 of the parameter value shall be encoded as the overflow/format octet (octet 4 of IP Timestamp)
- the remaining octets shall be used to encode the timestamp list
the size is fixed by the source, and it cannot be changed to accommodate additional timestamp information 🔒 so no sneaky resizing, bestie 💅
+--------+--------+--------+--------+
|11101110| length | pointer|oflw|flg|
+--------+--------+--------+--------+
| network entity title |
+--------+--------+--------+--------+
| timestamp |
+--------+--------+--------+--------+
| . |
.5. Error Reporting and Control Message Handling 🚨
okay this section is the drama 🎭 CLNP and IP differ in the way errors get reported to hosts, and it's lowkey a whole thing.
in IP environments, the Internet Control Message Protocol (ICMP, [7]) is used to send (error) messages back to hosts that originate packets that cannot be processed 📮 ICMP messages travel as user data inside IP datagrams. these things get reported:
- unreachable destinations
- incorrectly composed IP datagram headers
- IP datagram discards due to congestion
- lifetime/reassembly time exceeded
for each of those, the complete internet header that caused the error, plus (at least) 8 octets of the segment contained in that IP datagram, gets returned to the sender as part of the ICMP error message 🧾 for certain errors, like incorrectly composed IP datagram headers, the specific octet that caused the problem is identified 🔍
in CLNP environments, there's a unique message type, the Error Report type ✨ it's used in the network layer protocol header to tell Error Reports apart from CLNP datagrams. CLNP Error Reports are generated on detection of the same types of errors as ICMP 🫶 just like ICMP error messages, the complete CLNP header that caused the error is returned to the sender in the data portion of the Error Report.
Implementations SHOULD return at least 8 octets of the datagram contained in the CLNP datagram to the sender of the original CLNP datagram 💖 and again, for certain errors, the specific octet that caused the problem is identified 🦋
here's a summary of the CLNP Error Report, as it's proposed for use in TUBA environments 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........Data Link Header........ | NLP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Header Length | Version | Lifetime (TTL)| 000 | Type=ER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOTAL Length of Error Report | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest Addr Len | Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROTO field | Src Addr Len | Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address | Reason for Discard (type/len) |
| | 1100 0001 | 0000 0010 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason for Discard | Options... |
| code | pointer | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that each tick mark represents one bit position.
Figure 5-1. Error Report Format5.1 Rules for processing an Error Report 📜
the following is a summary of the rules for processing an Error Report, and bestie, these are the rules we follow 💅
- An Error Report is not generated to report a problem encountered while processing an Error Report. no error-ception loops here 🙅♀️
- Error Reports MAY NOT be fragmented (hence, the fragmentation part is absent). 🚫
- The Reason for Discard Code field is populated with one of the values from Table 5-1.
- The Pointer field is populated with number of the first octet of the field that caused the Error Report to be generated. If it is not possible to identify the offending octet, this field MUST be zeroed. 🎯
- If the Priority or Type of Service option is present in the errored datagram, the Error Report MUST specify the same option, using the value specified in the original datagram. 🎀
- If the Security option is present in the errored datagram, the Error Report MUST specify the same option, using the value specified in the original datagram; if the Security option is not supported by the intermediate system, no Error Report is to be generated (i.e., "silently discard" the received datagram). 🔐 quiet exit, no drama 🤫
- If the Complete Source Route option is specified in the errored datagram, the Error Report MUST compose a reverse of that route, and return the datagram along the same path. 🔁 the reverse-route glow-up is iconic ✨
5.2. Comparison of ICMP and CLNP Error Messages 💅
okay so Table 5-1 is basically a cheat sheet that matches ICMP messages and codes to CLNP Error Type Codes 🧚 (all values are in Internet decimal)
CLNP Error Type Codes | ICMP Message (Type, Code)
----------------------------------|------------------------------------
Reason not specified (0) | Parameter Problem (12, 0)
Protocol Procedure Error (1) | Parameter Problem (12, 0)
Incorrect Checksum (2) | Parameter Problem (12, 0)
PDU Discarded--Congestion (3) | Source Quench (4, 0)
Header Syntax Error (4) | Parameter problem (12, 0)
Need to Fragment could not (5) | Frag needed, DF set (3, 4)
Incomplete PDU received (6) | Parameter Problem (12, 0)
Duplicate Option (7) | Parameter Problem (12, 0)
Destination Unreachable (128) | Dest Unreachable,Net unknown (3, 0)
Destination Unknown (129) | Dest Unreachable,host unknown(3, 1)
Source Routing Error (144) | Source Route failed (3, 5)
Source Route Syntax Error (145) | Source Route failed (3, 5)
Unknown Address in Src Route(146) | Source Route failed (3, 5)
Path not acceptable (147) | Source Route failed (3, 5)
Lifetime expired (160) | TTL exceeded (11, 0)
Reassembly Lifetime Expired (161) | Reassembly time exceeded (11, 1)
Unsupported Option (176) | Parameter Problem (12, 0)
Unsupported Protocol Version(177) | Parameter problem (12, 0)
Unsupported Security Option (178) | Parameter problem (12, 0)
Unsupported Src Rte Option (179) | Parameter problem (12, 0)
Unsupported Rcrd Rte (180) | Parameter problem (12, 0)
Reassembly interference (192) | Reassembly time exceeded (11, 1)Table 5-1. Comparison of CLNP Error Reports to ICMP Error Messages
Note 1, the big one 🙈 The current accepted practice for IP is that source quench should not be used. If it is used, implementations MUST not return a source quench packet for every relevant packet. TUBA/CLNP implementations are encouraged to adhere to these guidelines 💖
Note 2 is about the ICMP messages that have no CLNP Error Report Code at all 😭 There are no corresponding CLNP Error Report Codes for these two:
- Protocol Unreachable
(3, 2) - Port Unreachable
(3, 3)
[Note: Additional error code points available in the ER type code block can be used to identify these message types.]
6. Pseudo-Header Considerations 🦋
okay so UDP and TCP segments get a checksum to make sure they didn't get messed with along the way ✨ To double check they actually landed at the right place, a pseudo-header gets built from the info used to deliver the segment, and that gets thrown into the checksum math too 🫶
Before a UDP or TCP segment goes out, implementations MUST build this pseudo-header and attach it to the segment. It's made of the following info, which gets used when the CLNP datagram is composed (bestie, this is the list 💅):
Destination Address Length IndicatorDestination Address (including PROTO field)Source Address Length IndicatorSource Address (including Reserved field)A two-octet encoding of the Protocol valueTCP/UDP segment length
If the length of {source address length field + source address + destination address field + destination address } is not an integral number of octets, a trailing 0x00 nibble gets padded on. If GOSIP compliant NSAP addresses are used, this never happens (this is known as the Farinacci uncertainty principle) 🤓 The last byte in the Destination Address is 0x06 for TCP and 0x11 for UDP, and the Protocol field is encoded as 0x0006 for TCP and 0x0011 for UDP. If needed, an octet of zero gets added to the end of the UDP/TCP segment to pad the datagram to a length that's a multiple of 16 bits.
[Note: the pseudoheader is encoded in this manner to expedite processing, as it allows implementations to grab a contiguous stream of octets beginning at the destination address length indicator and terminating at the final octet of the source address; the PROTOCOL field is present to have a consistent representation across IPv4 and CLNP/TUBA implementations.]
Figure 6-1 shows what the pseudo-header looks like when both the source and destination addresses are maximum length 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest Addr Len | Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (PROTO) | Src Addr Len | Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | (Reserved) | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP/TCP segment length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6-1. Pseudo-header
7. Security Considerations 🔥
Security, bestie, this one's serious 😭 ISO CLNP is an unreliable network datagram protocol, and it's subject to the same security considerations as Internet Protocol ([5], [8]). The methods for conveying the same security handling information that's recommended for IP are described in Section 4.13.1, Security Option 🔐
8. Author's Address 🎀
David M. Piscitello
Core Competence
1620 Tuckerstown Road
Dresher, PA 19025
Phone: 215-830-0692
EMail: wk04464@worldlink.com
9. References 📚
[1] ISO/IEC 8473-1992. International Standards Organization -- Data Communications -- Protocol for Providing the Connectionless Network Service, Edition 2.
[2] Callon, R., "TCP/UDP over Bigger Addresses (TUBA)", RFC 1347, Internet Architecture Board, May 1992.
[3] Postel, J., "Transmission Control Protocol (TCP)", STD 7, RFC 793, USC/Information Sciences Institute, September 1981.
[4] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, USC/Information Sciences Institute, September 1981.
[5] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.
[6] Chapin, L., "ISO DIS 8473, Protocol for Providing the Connectionless Network Service", RFC 994, March 1986.
[7] Postel, J., "Internet Control Message Protocol (ICMP)", STD 5, RFC 792, USC/Information Sciences Institute, September 1981.
[8] Braden, R., Editor, "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, Internet Engineering Task Force, October 1989.
[9] Hagens, R., "An Echo Function for ISO 8473", RFC 1139, IETF-OSI Working Group, May 1993.
[10] Sklower, K., "Improving the Efficiency of the ISO Checksum Calculation" ACM SIGCOMM CCR 18, no. 5 (October 1989):32-43.
[11] ISO/IEC 8348-1992. International Standards Organization--Data Communications--OSI Network Layer Service and Addressing.
[12] Callon, R., Gardner, E., and R. Hagens, "Guidelines for OSI NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC, July 1991.
[13] Piscitello, D., "Assignment of System Identifiers for TUBA/CLNP Hosts", RFC 1526, Bellcore, September 1993.
[14] ISO/IEC 9542:1988/PDAM 1. Information Processing Systems -- Data Communications -- ES/IS Routeing Protocol for use with ISO CLNP -- Amendment 1: Dynamic Discovery of OSI NSAP Addresses by End Systems.
[15] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340 USC/Information Sciences Institute, July 1992.
[16] Kent, S., "Security Option for IP", RFC 1108, BBN Communications, November 1991.
Appendix A. Checksum Algorithms (from ISO/IEC 8473) ✨
okay bestie, this is the checksum appendix, and it's lifted straight from ISO/IEC 8473 💅 let's start with the symbols so the algorithms make sense 🎀
Symbols used in algorithms:
c0,c1: variables used in the algorithmsi: position of octet in header (first octet is i=1)Bi: value of octet i in the headern: position of first octet of checksum (n=8)L: Length of header in octetsX: Value of octet one of the checksum parameterY: Value of octet two of the checksum parameter
Addition happens in one of two modes, pick your fighter 🥊
- modulo 255 arithmetic;
- eight-bit one's complement arithmetic;
The algorithm for Generating the Checksum Parameter Value goes like this 🦋
A. Build the whole header with the checksum parameter field set to zero, i.e., c0 <- c1 <- 0;
B. Go through each octet of the header in order, from i=1 to L, and do this:
c0 <- c0 + Bic1 <- c1 + c0
C. Work out X and Y like this:
X <- (L - 8)(c0 - c1) modulo 255Y <- (L - 7)(-C0) + c1
D. If X = 0, then X <- 255
E. If Y = 0, then Y <- 255
F. Put the values of X and Y into octets 8 and 9 of the header, respectively 🌸
The algorithm for checking the value of the checksum parameter is next 🧚
A. If octets 8 and 9 of the header both hold zero, then the checksum calculation has succeeded. Else, if only one of those two octets holds zero, then the checksum is incorrect. Otherwise, initialize: c0 <- c1 <- 0
B. Go through each octet of the header in order, from i = 1 to L, and do this:
c0 <- c0 + Bic1 <- c1 + c0
C. Once every octet has been processed, if c0 = c1 = 0, then the checksum calculation has succeeded. Otherwise, it has failed. 💀
there's also a separate algorithm for when one octet gets modified, like the TTL. Say the value in octet k changes byZ = newvalue - oldvalue. IfXandYare the checksum values sitting in octets n and n+1 respectively, then adjust them like so 🫶
If X = 0 and Y = 0, then do nothing. Else, if X = 0 or Y = 0, then the checksum is incorrect. Otherwise:
X <- (k - n - 1)Z + X modulo 255
Y <- (n - k)Z + Y modulo 255If X = 0, then X <- 255; if Y = 0, then Y <- 255.
In the example, n = 89. If the octet altered is the TTL (octet 4), then k = 4. When the lifetime goes down by one unit (Z = -1), the assignment statements for the new values of X and Y in the immediately preceeding algorithm simplify to 👑
X <- X + 5 Modulo 255
Y <- Y - 4 Modulo 255📦 where this page comes from
- ietf: rfc1561 1993-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms