DRAFT - Tools RFC S. Hares and C. Wittbrodt March 14, 1992 version 1 1 Draft - TOOLS RFC March 14, 1992 1. STATUS This memo specifies tools which are necessary to debug problems in the deployment and maintenance of networks using ISO 8473[1], the connectionless network layer protocol (CLNP). This document will be submitted to the RFC editor as a proposed standard for the OSI Internet. To support some of the needed tools (ping and traceroute) this memo specifies the long term mechanism outlined in RFC1139 [2]. RFC 1139 specifies that when an ISO standard is adopted that provides functionality similar to that described by RFC 1139, then RFC 1139 will be come obsolete and superseded by the ISO standard. ISO work is progressing on an ISO echo function, but not completed yet and at this time, there is no estimated date of completion. When an echo function is defined for an ISO standard, both the RFC 1139 echo function and the ISO echo function will need to be supported for a period of transition. Once the ISO echo function has been adopted (and RFC 1139 obsolete by the ISO standard), an RFC defining the transition period for support of both echo functions will be written to supersede this document. 2. ABSTRACT This memo specifies the following three necessary tools to debug problems in the deployment and maintenance of networks using ISO 8473 (CLNP): - ping or ISO Echo function - traceroute function which uses the ISO Echo function - routing table dump function 3. INTRODUCTION Currently in the Internet, OSI protocols are being used more and more. As the network managers of an Internet once predominantly a TCP/IP network began deploying parts of the emerging OSI Internet, it became apparent that network layer ISO network debugging tools were for almost nonexisting. When such tools existed, different implementations didn't work together. 2 As stated in RFC 1139 a simple network layer mechanism is necessary to allow systems to be probed to test network layer integrity. RFC 1139 goes on to describe two different ping capabilities, one a long term solution, and one a short term solution. The problem becoming more and more prevalent in the OSI Internet is that some vendors implemented the short term solution and some implemented the long term one. The two solutions do not work together, i.e., a ping from a host with the short term version to one with the long term version will not work, and visa versa. Also, some hosts and routers have not implemented a ping at all. The two solutions provided to simplify the situation, have instead complicated it. 4. SPECIFICATION This document's purpose is to specify a standard ping, traceroute, and OSI routing table dumping mechanisms for use for the ISO 8473 (CLNP) protocol in the OSI Internet. A detailed description of the specified mechanisms is below. These mechanism should 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 for the Internet. 4.1. PING Protocol Support ----------------- The long term echo mechanism, as described in RFC 1139, requires the use of two new type values in the packet header of the ISO 8473 Network Protocol Data Units (NPDUs). The two values are: 1E(hex) - for the Echo Request Selector and, 1F(hex) - for the Echo Reply Selector. Nodes which support ISO 8473 but do not support these two new values (for the type code option field in the header of an ISO 8473 (NPDU) will send back an error packet IF the ERROR report flag is set in the NPDU. 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 1139 AND also set the ERROR report flag in the 8473 header. The setting of the ERROR report flag is required because this allows a way for a compliant host or router to ping a 3 DRAFT - OSI Tools March 14, 1991 non-compliant host or router. When a non-complaint host or router receives a "ping" NPDU with the new type function (Echo Request Selector), it will send back an ISO 8473 ER NPDU to the originating host. 4.1.2) Functions to be supported in "ping" utility A ping utility should able to provide the Round trip time of each packet, plus the average minimum and maximum RTT over several ping packets. When an ER NPDU is received by the node, the ping utility should report the error code to the user. 4.2. TRACEROUTE The CLNP trace is similar to the ping utility except that it utilizes the "Lifetime" field in the ISO 8473 NPDU. The "Lifetime" field serves the same function as the Time To Live (TTL) field does in an IP packet. A node (router or host) cannot forward ISO 8473 NPDU with a value for the Lifetime of zero. If the ERROR REPORT flag is set in the ISO 8473 PDU, an ER (error) NPDU will be returned to the originator of the packet. 4.2.1) Basic TRACEROUTE If a ISO 8473 PDU with a type code of Echo-request is sent with "Lifetime" field value of 1, the first hop node (router or end system) will either return an ER NPDU to the originator the NPDU. 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-assembly If the first hop node does not support "Echo-Request" type field, please return the Error code: B0 (hex) - Unsupported Option not Specified. When trying to trace a route to a remote note, the destination address in the Echo-Request PDU sent should be this 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) to allow a user to trace a network path to a remote host. 4 DRAFT - OSI Tools March 14, 1991 The error message is used as evidence of what the first hop was. The originator then sends a packet with a "lifetime" field value of 2. The first hop decrements the "Lifetime" and because the "Lifetime" is still greater than 0, it forwards it on. The second hop decrements the "Lifetime" field value and sends an Error PDU (ER NPDU) with one of the two "Lifetime Expired" error codes listed above to the originator. This sequence is repeated until either: - the remote host is reached an either an Echo-Reply PDU is sent back or (for nodes that do not have the required Echo support) an ER PDU is sent back, or - the an ER PDU is received with error code (B0) indicating that a node will not pass the Echo-Reply packet, or - an ER NPDU 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 ER PDU, a second PDU should be sent by the originating node: Code Reason from 8473 ----------------------------- 00(hex) - Reason not specified 01(hex) - Protocol procedure error 02(hex) - Incorrect checksum 03(hex) - PDU Discarded due to Congestion 04(hex) - Header Syntax Error (cannot be parsed) 05(hex) - Segmentation needed but not permitted 06(hex) - Incomplete PDU 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 Interface If one of these error is detected, please return the error value to the user. More than two Echo NPDUs, may be sent at a "Lifetime" value. The number of additional echo NPDUs 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 NPDU, send a second Echo-Request NPDU to the destination at a "Lifetime" value: 5 DRAFT - OSI Tools March 14, 1991 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 NPDU may have been damaged in shipping through the network.) 4.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 routeing" function a ISO 8473 NPDU gets passed along the path "exactly as though the function has not been selected. The PDU shall not be discarded for this reason."[3] A partial source route function in the ISO Traceroute will set in the option fields the "source routeing" option, and the "partial source routeing" parameter within that option. To support a 3rd party or "loose source route" traceroute function, a node will send the Echo-Request NPDU with the "loose source routeing" field set. The functioning of the 3rd party/"loose source route" traceroute is the same except the following error cause the traceroute to be terminated: Code Reason from ISO 8473 -------------------------------------------------- 92 Unknown Address in Source Routeing Field 93 Path not Acceptable These errors may indicate a problem with the "loose source route" listed in the Echo-Request NPDU for this destination. Additional NPDUs with the same lifetime will only repeat this error. These errors should be reported to the user of the traceroute function. 4.2.3) Information needed from a Traceroute utility A traceroute utility should provide the following information to the user: - NET systems the pathway goes through, - ping times (in Round trip times) for each step of the way, - error codes from ER PDU received as a 6 DRAFT - OSI Tools March 14, 1991 response to the an Echo-Request packet, and - any other error conditions encounter by traceroute. 4.3. OSI routing table dump Each OSI host (end system) or router (intermediate system) need to be able to dump any of its routing tables. Routing tables may come from the: a.) the ES-IS information b.) static c.) IS-IS d.) IDRP or any other source. Each system must be able to dump the routing table entries from the console. A method must exist to provide these. It is suggested that a showosi routes command be created with the following 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. In addition, it is optional but highly recommended that the routing tables be available from via of the following network protocols: a.) SNMP Internet MIBs RFC 1238 CLNS MIB [4] NET of this router ES adjacencies, ES Connection Timer, ES hold timer IS Adjacencies RFC XXXX Integrated IS-IS MIB [5] (***Editor's note - this is the type of information 7 DRAFT - OSI Tools March 14, 1991 I think should be included, but I need feed back on this prior to specifying particular MIB variables.) IS Reachability information IS L1 Adjacencies IS L2 ADjacencies RFC XXXX IDRP MIB [6] (***Editor's note - this is the type of information I think should be included, but I need feed back on this prior to specifying particular MIB variables.) per BIS router: InternalBIS, IntraIS, ExternalBISNeighbor, Internal Systems, LocalRDI, RDC-Config, Local-SNPA, MultiExit, RouteServer holdTime, CloseWaitDelay Local RIB Local FIB per BIS neighbor: BIS_NET BIS_RDI BIS_RDC Adj-RIB information b.) CMIP agent ISO 10733 [7] (Common network layer) Section 6.4) Network Entity Managed Object networkEntityTitles linkage-ISO9542ES-P HoldingTimerMultipler manualISSNPAAddress defaultESConfigTimer activeESConfigTimer isReachabilityChanges linkage-ISO9542IS-P holdingTimerMultiplier isConfigurationTimer suggestedESConfigurationTimer 8 DRAFT - OSI Tools March 14, 1991 redirectHoldingTimer eSReachabilityChanges ISO 10589 [8] (IS-IS) - GDMO (***Editor's note - this is the type of information I think should be included, but I need feed back on this prior to specifying particular MIB variables.) IS Reachability information IS L1 Adjacencies IS L2 ADjacencies ISO 10747 [3] (IDRP) - GDMO (***Editor's note - this is the type of information I think should be included, but I need feed back on this prior to specifying particular MIB variables.) per BIS router: InternalBIS, IntraIS, ExternalBISNeighbor, Internal Systems, LocalRDI, RDC-Config, Local-SNPA, MultiExit, RouteServer holdTime, CloseWaitDelay Local FIB Local RIB per BIS neighbor: BIS_NET BIS_RDI BIS_RDC Adj-RIB information 9 DRAFT - OSI Tools March 14, 1991 5. REFERENCES [1] ISO/IEC 8473, Information Processing Systems, "Protocol for Providing the Connectionless-mode Network Service and Provision of Underlying Service". May, 1987. [2] R. Hagens, "An Echo Function for ISO 8473", Request For Comment #1139, January 1990. DDN Network Information Center, SRI International. [3] 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 PDUs. [4] RFC 1238 CLNS MIB (Greg Satz) - for use with Connectionless Network Protocol (ISO 8473) and End system to Intermediate System Protocol (ISO 9452) [5] RFC xxx Integrated IS-IS MIB - (Chris Gunner) [6] RFC xxxx IDRP MIB (Hares) [7] ISO/IEC 10733 - Information Technology - Telecommunications and Information Exchange between Systems - Elements of Management Information Relating to OSI Network Layer Standards [8] ISO/IEC 10589 - Information Processing Systems - Telecommunications and Information Exchange between Systems - Protocol for Exchange of Intra-Domain Routeing Information among Intermediate Systems. 10 DRAFT - OSI Tools March 14, 1991 TABLE OF CONTENTS Section 1 STATUS ...................................... 2 Section 2 ABSTRACT .................................... 2 Section 3 INTRODUCTION ................................ 2 Section 4 SPECIFICATION ............................... 3 Section 4.1 PING ...................................... 3 Section 4.2 TRACEROUTE ................................ 4 Section 4.3 OSI routing table dump .................... 7 Section 5 REFERENCES .................................. 11 11