RFC 1574
Essential Tools for the OSI Internet
RFC 1574: Essential Tools for the OSI Internet 🎀
Okay bestie, let's get into it! 💖 This is RFC 1574, called Essential Tools for the OSI Internet. It came out of the Network Working Group in February 1994 and it's Informational 🌸, which means it doesn't specify an Internet standard. The authors are S. Hares (Merit/NSFNET) and C. Wittbrodt (Stanford University/BARRNet), and it obsoletes RFC 1139 ✨.
Status of this Memo 📜
This memo gives info to the Internet community 🧚. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Abstract 🦋
This doc specifies the following three necessary tools to debug problems in deploying and maintaining networks that use ISO 8473 (CLNP):
- ping or OSI Echo function
- traceroute function which uses the OSI Echo function
- routing table dump function
These CLNS tools are the basics that hosts and routers need for CLNS network support 💅. It's meant to specify the most basic support level required for CLNS hosts and routers.
To support some of the needed tools (ping and traceroute), this memo specifies the mechanism from RFC 1575 [3] 💜.
Table of Contents 📚
Section 1. Conventions ....................................... 2
Section 2. Introduction ...................................... 2
Section 3. Specification ..................................... 2
Section 3.1 Ping ............................................. 3
Section 3.1.1 Protocol Support ............................... 3
Section 3.1.2 Functions supported by the ping utility ........ 3
Section 3.2 Traceroute ....................................... 3
Section 3.2.1 Basic Traceroute ............................... 4
Section 3.2.2 Use of Partial Source route in traceroute ...... 5
Section 3.2.3 Information needed from a Traceroute utility ... 6
Section 3.3 OSI routing table dump ........................... 6
Section 3.4 MIB variables available via SNMP ................. 7
Section 3.4.1 Summary of MIB Variables ....................... 8
Section 3.4.2 ASN.1 Syntax for these MIB variables ........... 8
Section 4. OSI HOST.txt format ............................... 10
Section 5. Acknowledgements .................................. 11
Section 6. References ........................................ 12
Section 7. Security Considerations ........................... 12
Section 8. Author's Addresses ................................ 131. Conventions ✨
The following language conventions are used in the items of specification in this document:
- 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 🫶.
- MAY or OPTIONAL: the item is truly optional. You can follow it or ignore it, depending on what the implementor needs 🌈.
2. Introduction 🌈
Okay so OSI protocols are being used more and more these days 👑. When network managers of an Internet that was mostly TCP/IP started deploying parts of the emerging OSI Internet, it became super clear that network layer OSI debugging tools were almost nonexistent 😭. When tools did exist, different implementations didn't work together. Not it.
As stated in RFC 1575, a simple network layer mechanism is needed so systems can be probed to test network layer integrity 🔍. The authors believe that for running OSI networks, other tools are needed too. The tools described below are an echo function, a traceroute function, and a routing table dump. This document defines the minimum subset of tools needed to debug network problems, and that's the whole vibe 🍓.
3. Specification 🔥
This document's purpose is to specify standard ping, traceroute, and OSI routing table dumping mechanisms for use with the ISO 8473 (CLNP) protocol in the OSI Internet 💖. A detailed description of the specified mechanisms is below. These mechanisms MUST be available on every router (intermediate system) or host (end system) that provides OSI service for the Internet. These three functions are the basic tool set for the OSI network layer on the Internet, and they're iconic 👑.
3.1. Ping 🏓
3.1.1. Protocol Support 💌
The long term echo mechanism, as described in 1575, needs two new type values in the packet header of ISO 8473 Network Protocol Data Units (NPDUs), or preferably packets. The two values are:
1E(hex) - for the echo-request Selector and,
1F(hex) - for the echo-response Selector.Nodes that support ISO 8473 but don't support these two new values (for the type code option field in the header of an ISO 8473 packet) MUST send back an error packet if the ERROR report flag is set in the packet 🙈.
To support a ping function for ISO 8473, all end systems (hosts) and intermediate systems (routers) MUST support the "long term" echo function as defined by RFC 1575 [3] AND also set the ERROR report flag in the 8473 header 🌸.
Setting the ERROR report flag is required because it gives a compliant host or router a way to ping a non-compliant host or router 🦋. When a non-compliant host or router receives a "ping" packet with the new type function (Echo Request Selector), it MUST attempt to return an ISO 8473 error packet to the originating host, which shows reachability ✨.
3.1.2. Functions supported by the ping utility 🧁
A ping utility MUST be able to provide the Round trip time of each packet, plus the average, minimum, and maximum RTT over several ping packets 📊. When an error packet is received by the node, the ping utility MUST report the error code to the user 💅.
3.2. Traceroute 🗺️
The CLNP trace is similar to the ping utility, except that it uses the "Lifetime" field in the ISO 8473 packet 🧚. Hosts and routers that support OSI MUST also support CLNP trace. The "Lifetime" field does the same job as the Time To Live (TTL) field in an IP packet, so it's giving TTL energy 💜. A node (router or host) cannot forward an ISO 8473 packet with a Lifetime of zero. If the ERROR REPORT flag is set in the ISO 8473 packet, an error packet will be returned to the originator of the packet 🔥.
3.2.1. Basic Traceroute 🛤️
If an ISO 8473 echo-request packet is sent with a "Lifetime" field value of 1, the first hop node (router or end system) will return an error packet to the originator of the packet. If the first hop node supports the echo-request type field, the error code will be either:
A0 (hex) - Lifetime Expired while Data Unit in Transit
A1 (hex) - Lifetime Expired during Re-assemblyIf the first hop node does not support the echo-request type field, the error code will be:
B0 (hex) - Unsupported Option not Specified.When you're trying to trace a route to a remote node, the destination address in the echo-request packet sent should be that remote destination 🎀. By using increasing values in the "Lifetime" field, a route can be traced through the network to the remote node. This traceroute function should be implemented on each system (host or router) so a user can trace a network path to a remote host or router 🌈.
The error message is used as evidence of the reachability and identity of the first hop 🫶. The originator then sends a packet with a "lifetime" field value of 2. The first hop decrements the "Lifetime". Because the "Lifetime" is still greater than 0, it forwards the packet on. The second hop decrements the "Lifetime" field value and sends an error packet (ER NPDU) with one of the two "Lifetime Expired" error codes listed above to the originator. This keeps going until either:
- the remote host is reached and either an echo-response packet is sent back or (for nodes that do not have the required Echo support) an error packet is sent back, or
- an error packet is received with error code (B0) indicating that a node will not pass the echo-response packet, or
- an error packet is received with one of the following errors:
80(hex) - Destination Address Unreachable
81(hex) - Destination Address Unknown.If any of the following Error codes are received in an error packet, a second packet should be sent by the originating node 🧠:
CodeReason from 8473
-----------------------------
00(hex) - Reason not specified
01(hex) - Protocol procedure error
02(hex) - Incorrect checksum
03(hex) - Packet Discarded due to Congestion
04(hex) - Header Syntax Error (cannot be parsed)
05(hex) - Segmentation needed but not permitted
06(hex) - Incomplete packet received
07(hex) - Duplicate Option
B1(hex) - Unsupported Protocol Version
B2(hex) - Unsupported Security Option
B3(hex) - Unsupported Source Routeing Option
B4(hex) - Unsupported Recording of Route Option
C0(hex) - Reassembly InterfaceIf one of these errors is detected, an error value should be returned to the user. More than one echo packet may be sent at a "Lifetime" value. The number of additional echo packets is left up to the implementation of this traceroute function 🌸.
If one of the following errors is received, AND "partial source route" is not specified in the echo-request packets, send a second echo-request packet to the destination at a "Lifetime" value 🦋:
Code Reason from 8473
--------------------------------
90(hex) Unspecified Source Routeing Error
91(hex) Syntax Error in Source Routeing Field
92(hex) Unknown Address in Source Routeing Field
93(hex) Path not Acceptable(The echo-request packet may have been damaged while traversing the network 😭.)
3.2.2. Use of Partial Source route in traceroute 🧭
The current IP traceroute has a 3rd party or "loose source route" function. The ISO 8473 protocol also supports a "partial source routeing" function. However, if a node (router or host) does not support the "partial source routing" function, an ISO 8473 packet gets passed along the path "exactly as though the function has not been selected. The packet shall not be discarded for this reason." [2] 🍓
In order to utilize the partial source route function in the OSI traceroute, a node must set the "source routeing" option and the "partial source routeing" parameter within that option. A 3rd party, or "loose source route," traceroute function requires that a node send an echo-request packet with the "loose source routeing" field set. The 3rd party/"loose source route" traceroute works the same way, except the following errors cause the traceroute to be terminated 💅:
Code Reason from ISO 8473
--------------------------------------------------
92 Unknown Address in Source Routeing Field
93 Path not AcceptableThese errors may indicate a problem with the "loose source route" listed in the echo-request packet for this destination. Additional packets with the same lifetime will only repeat this error. These errors should be reported to the user of the traceroute function 🙈.
to be continued in part 2 💜
3.2.3. Information needed from a Traceroute utility ✨
Okay, so a traceroute utility should show the user all of this 💅
- the identity of the systems that make up the path or route to the destination (these identifiers are called Network Entity Titles or NETs in OSI and ISO 8473) 🗺️
- ping times (in Round trip times) for each hop in the path ⏱️
- error codes from error packets received as a response to an echo-request packet 🚨
- any other error conditions traceroute runs into 🙈
3.3. OSI routing table dump 🗂️
Every OSI host (end system) or router (intermediate system) MUST be able to dump any of its routing tables. The routing tables can come from:
a.) the ES-IS information
b.) static
c.) IS-IS
d.) IDRPor any other source.
Each system MUST be able to dump the routing table entries via some out of band mechanism. A method MUST exist to provide these. A show osi routes command SHOULD be created with these options:
- a for all routes
- esis for es-is routes
- isis for is-is routes
- idrp for idrp routes
- static for static routes
- other for routes from other sources.Also, routing tables SHOULD be available via either SNMP or CMIP. The specification of CMIP variables is outside the scope of this spec. Section 3.4 specifies the RFC 1238 MIB variables, which MUST be available via SNMP. These two variables simply let the user grab some basic CLNS routing info 🦋
Please note that not all the information requested is available via the CLNS MIB. Because of this, it's expected that more work on a CLNS MIB will happen in the future. When a new MIB is written, this document is expected to be updated to include the extra MIB variables that collect things like the ES-IS cache 📝
3.4. MIB variables available via SNMP 📊
The Simple Network Management Protocol [6] is a big deal for keeping an eye on multi-protocol, managed resources across the Internet. By convention, SNMP is mapped onto User Datagram Protocol (UDP), 6); however, when it isn't possible to talk to an ISO 8473 managed resource using SNMP over UDP, or when using SNMP/UDP to reach an ISO 8473 managed resource is not possible/appropriate, SNMP messages should be mapped onto an OSI transport (7) The following Managed Objects for the SNMP SHOULD be supported to make remote monitoring with SNMP work 🫶
Okay, again, the same idea in different words: SNMP (the Simple Network Management Protocol) plays a major role in monitoring multi-protocol, managed resources on the Internet. By convention, SNMP is mapped onto User Datagram Protocol (UDP); however, in those situations where it is not possible to communicate with an ISO 8473 managed resource using SNMP over UDP, or where communication with an ISO 8473 managed resource using SNMP/UDP is not possible/appropriate, SNMP should be mapped onto an OSI transport (8). The following Managed Objects SHOULD be supported for remote monitoring using SNMP 🔥
3.4.1. Summary of MIB Variables 🎀
RFC 1238 CLNS MIB [5]
1) clnpAddrTable - Addresses for Interfaces
2) clnpRoutingTable - OSI routes in system routing table.3.4.2. ASN.1 Syntax for these MIB variables 🧠
The ASN.1 syntax for the two variables in the CLNS MIB (RFC 1238) is included below for easy reference. That RFC remains the authoritative source for the MIB definitions 💜
1) clnpAddrTable
clnpAddrTable OBJECT-TYPE
object.id = .... {clnp 21 }
clnpAddrTable = SEQUENCE OF ClnpAddrEntry
CLNPAddrEntry ::= SEQUENCE {
clnpAdEntAddr
CLNPAddres,
clnpAdEntIfIndex,
INTEGER,
clnpAdEntReasmMaxSize
INTEGER (0...65535);
}
clnpAdEntAddr = ClnpAddress
clnpAddress = OCTET string (Size (1...20);
clnpAdEntIfIndex = INTEGER;
clnpAdEntReasmMaxSize = INTEGER (0...65535); #Here's what the table entry values mean:
clnpAdEntAddr - CLNP address for this interface value
clnpAdEntIfIndex - Interface Index value corresponding to
IfIndex value.
clnpAdEntReasmMaxSize = Maximum size of a pdu that can be
reassembled from incoming PDUs
received on this interface. 2) clnpRoutingTable
object id =....{clnp 22}
clnpRoutingTable = SEQUENCE OF ClnpRouteEntry;
ClnpRouteEntry = SEQUENCE OF {
clnpRouteDest,
clnpRouteIfIndex,
clnpRouteMetric1,
clnpRouteMetric2,
clnpRouteMetric3,
clnpRouteNextHop,
clnpRouteType,
clnpRouteProto,
clnpRouteAge,
clnpRouteInfo}
clnpRoutDest ::= ClnpAddress; # Address in Route table
# (prefix or full address
clnpRouteIfIndex ::= Integer; # IfIndex value for
# interface next hop can
# be reached through.
clnpRouteMetric1 ::= Integer; # primary routing metric
# for this protocol.
# Specific meaning
# depends on clnpRouteProto
# value -1 if not used
clnpRouteMetric2 ::= Integer; # alternate routing metric
# for this protocol.
# Specific meaning
# depends on clnpRouteProto
# value -1 if not used
clnpRouteMetric3 ::= Integer; # alternate routing metric
# for this protocol.
# Specific meaning
# depends on clnpRouteProto
# value -1 if not used
clnpRouteMetric4::= Integer; # alternate routing metric
# for this protocol.
# Specific meaning
# depends on clnpRouteProto
# value -1 if not used
clnpRouteNextHop::= ClnpAddress; # Address of Next Hop in
# Routing
# Table
clnpRouteType::=INTEGER {
other (1), # none of following
invalid (2), # an invalid route
direct(3), # a direct route
remote(4)} # a remote route
clnprouteProto::= INTEGER {
other (1), # none of the following
# (manually configured
# falls in this category)
local(2), # configured entries
netmngt(3), # set via Network
# management
is-is(9), # ISO 10589
ciscoIgrp(11), # Ciscos OSI IGRP
ospf(13), # OSPF set
bgp(14), # BGP sets
idrp(15) # addition suggested to
# rfc 1238
# in processing
clnpRouteMetric5::= Integer; # alternate routing metric
# for this protocol.
# Specific meaning
# depends on clnpRouteProto
# value -1 if not used
clnpRouteInfo ::= OBJECT-ID; # protocol id that
# installed this route
}4. OSI HOST.txt format 🧚
The OSI address format lets addresses be 20 bytes long 🌈 In the long term, a Directory service (DNS service or OSI Directory service (X.500)) will provide a host name to address mapping. Getting OSI-capable DNS and Directory service may require an OSI pathway to already be set up first 😭 Most host and router systems use a fixed table to map names to NSAP addresses so OSI works on their system. The current problem is that every implementation uses a different format. This document defines one fixed format so these initial name-to-NSAP mapping files can be shared throughout the internet 🫶
To conform to this document, a host or router supporting CLNS MUST support an osi host.txt file with the format below. The osi host.txt file may be used for other OSI applications or TUBA applications. For these other applications, other fields may be defined, but defining them is outside the scope of this specification ✨
OSI applications may use another file name for OSI address information. NSAP addresses in any OSI address information MUST use the format below. This host name to NSAP mapping MUST be available for use by the following utilities on CLNS hosts and routers:
- OSI Echo (Ping) function,
- OSI traceroute function, and
- router table look-up for CLNS routing information
Host and router systems MUST also support an NSAP to name mapping through the Domain Name Service Directory or the OSI Directory service (X.500) 💅
Here's the format of the OSI hosts file:
<NSAP Address> <name1> <name2> ...<name>The NSAP Address should be in the following format:
<first octet>.<2nd octet 3rd octet>.<4th octet 5 octet>.A few notes on the format above:
The NSAP octets should be expressed in hexadecimal. The dots are just there to make the address easier to read, and they MUST NOT be required for parsing an NSAP address. However, each NSAP address file MUST be able to handle the insertion of dots. Where the dots go within an NSAP address MUST NOT have any significance other than making the address easier to read 🤓
Here's an example of this in GOSIP format:
47.0005.80ff.ff00.0000.0001.0001.0a0b.0c0d.0204.00And here's one in ANSI format:
39.480f.8000.0500.0000.0001.0001.0a0b0c0d.0204.00This value quickly shows the AFI and the NSEL octets on either end 👑
<name1> <name2> <name> indicates a sequence of names associated with this NSAP address 🦋
5. Acknowledgements ✨
okay bestie, big thank-you energy here 🫶 the authors shoutout Dave Piscitello, who kept the doc accurate AND helped them ditch the ISO jargon so it's actually readable (iconic behavior fr 💅). Thanks also to Paulina Knibbe for the host.txt format work 🧚. And they thanked the members of the Network OSI Operations Working Group of the IETF for their comments 💖
6. References 📚
Here's the reading list, no cap 🤓
- [1] ISO/IEC 8473, Information Processing Systems, "Protocol for Providing the Connectionless-mode Network Service and Provision of Underlying Service", May 1987.
- [2] Hagens, R., "An Echo Function for ISO 8473", RFC 1139, IETF-OSI Working Group, January 1990.
- [3] Hares, S., and C. Wittbrodt, "CLNP echo (ISO 8473)", RFC 1575, Merit/NSFNET, Stanford University/BARRNet, February 1994.
- [4] ISO/IEC DIS 10747 Information Processing Systems - Telecommunications and Information Exchange between Systems - Protocol for Exchange of Inter-domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 packets.
- [5] Satz, G., "Connectionless-mode Network Service Management Information Base - for use with Connectionless Network Protocol (ISO 8473) and End system to Intermediate System Protocol (ISO 9452)", RFC 1238, cisco Systems, Inc., June 1991.
- [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990.
- [7] Rose, M., "SNMP over OSI", RFC 1418, Dover Beach Consulting, Inc., March 1993.
- [8] Information processing systems - Open Systems Interconnection - Protocol for Providing the Connectionless-mode Transport Service, International Organization for Standardization. International Standard 8602, December 1987.
7. Security Considerations 💀
Okay, the big reveal: security issues are not discussed in this memo 🙈 so there's nothing more to say here, but it's still worth keeping your guard up when you're implementing this stuff bestie 🔥
8. Authors' Addresses 🎀
Here's where you can reach the authors 💌
Susan K. Hares MERIT/NSFNET Internet Engineering 1075 Beal Avenue Ann Arbor, MI 48109-2112
Phone: (313) 936-3000 EMail: skh@merit.edu
Cathy J. Wittbrodt Stanford University/BARRNet Networking Systems Pine Hall 115 Stanford, CA 94305
Phone: (415) 725-5481 EMail: cjw@magnolia.Stanford.EDU
📦 where this page comes from
- ietf: rfc1574 1994-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms