OSI Tools RFC - FYI
skh@merit.edu Tue, 10 November 1992 16:22 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05716; 10 Nov 92 11:22 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05704; 10 Nov 92 11:22 EST
Received: from p.lanl.gov by CNRI.Reston.VA.US id aa09949; 10 Nov 92 11:23 EST
Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA28857; Tue, 10 Nov 92 09:11:35 -0700
Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA14704; Tue, 10 Nov 92 09:11:12 MST
Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA14700; Tue, 10 Nov 92 09:11:10 MST
Received: from merit.edu by p.lanl.gov (5.65/1.14) id AA28835; Tue, 10 Nov 92 09:11:07 -0700
Return-Path: <skh@merit.edu>
Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA03460; Tue, 10 Nov 92 11:10:50 -0500
Received: by home.merit.edu (4.1/client-0.9) id AA17976; Tue, 10 Nov 92 11:10:49 EST
Date: Tue, 10 Nov 1992 11:10:49 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: skh@merit.edu
Message-Id: <9211101610.AA17976@home.merit.edu>
To: noop@merit.edu, tuba@lanl.gov, x3s33@merit.edu
Subject: OSI Tools RFC - FYI
Cc: cjw@nersc.gov, skh@merit.edu
Hi all: Here's a copy of the OSI tools document. It describes a list of OSI functions which as basic tools needed to build an CLNP internet. Please send any comments to the noop@merit.edu mail list or the x3s33@merit.edu mail list. This document is currently an Internet Draft. We hope to push it toward a standards track - like host requirements. We will be discussing this final form at the NOOP working group meeting at IETF on 11/18 1:30pm - 3:30pm. Thank-you, Susan Hares NOOP co-chair cut here ----------- DRAFT - Tools RFC S. Hares and C. Wittbrodt November 9, 1992 Draft - TOOLS RFC November 9, 1992 1. STATUS This memo specifies tools which are necessary to debug prob- lems 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 pro- posed standard for the OSI Internet. To support some of the needed tools (ping and traceroute) this memo specifies the mechanism specified in RFC1139 [2]. RFC 1139 is intended to mirror the work that is currently going on within the ISO community. ISO work is progressing on an ISO echo function, but not completed yet and at this time, there is no estimated date of completion. A revised RFC 1139 reflects the current RFC's work [3]. 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. TABLE OF CONTENTS Section 1 STATUS ...................................... 2 Section 2 ABSTRACT .................................... 2 Section 3 TABLE OF CONTENTS............................ 2 Section 4 INTRODUCTION ................................ 2 Section 5 SPECIFICATION ............................... 3 Section 5.1 PING ...................................... 3 Section 5.1.1 Protocol ................................ 3 Section 5.1.2 Functions ............................... 3 Section 5.2 TRACEROUTE ................................ 4 Section 5.2.1 Basic ................................... 4 Section 5.2.2 Use ..................................... 6 Section 5.2.3 Information ............................. 6 Section 5.3 OSI ....................................... 7 Section 5.3.1 SNMP .................................... 7 Section 5.3.1.1 RFC ................................... 8 Section 5.3.1.2 RFC ................................... 8 Section 5.3.2 CMIP .................................... 8 Section ISO 10733 (Network Layer Management info) [8] . 8 Section ISO 10589 (IS-IS Management info) [9] ......... 9 Section ISO 10747 (IDRP Management info) [4] .......... 9 Section 10748 REFERENCES .............................. 10 Page 2 Draft - TOOLS RFC November 9, 1992 4. 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 almost nonexistant. When such tools existed, different implementations didn't work together. 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 imple- mented 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. The revised version of RFC 1139 specifies only the long term solution. Certain wording in the error handling section have been revised to match the current ISO work. 5. SPECIFICATION This document's purpose is to specify a standard ping, tra- ceroute, 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 (inter- mediate system) or host (end system) that provides OSI ser- vice for the Internet. These three functions are the basic tool set for the OSI network layer for the Internet. 5.1. PING 5.1.1. Protocol The long term echo mechanism, as described in RFC1139, 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. Page 3 Draft - TOOLS RFC November 9, 1992 Nodes which support ISO8473 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-Revised 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 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, thus showing reachability. 5.1.2. Functions 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. 5.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. 5.2.1. Basic 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 Page 4 Draft - TOOLS RFC November 9, 1992 field, the Error code will be: B0 (hex) - Unsupported Option not Specified. When trying to trace a route to a remote node, the destina- tion 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 or router. The error message is used as evidence of the reachablity 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" 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: Page 5 Draft - TOOLS RFC November 9, 1992 CodeReason 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, an error value should be returned to the user. More than one Echo NPDU, 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: 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.) 5.2.2. Use 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 route- ing" function an 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."[2] Page 6 Draft - TOOLS RFC November 9, 1992 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. 5.2.3. Information A traceroute utility should provide the following informa- tion to the user: - NET of systems the pathway goes through, - ping times (in Round trip times) for each hop in the path, - error codes from ER PDU received as a response to the an Echo-Request packet, and - any other error conditions encountered by traceroute. 5.3. OSI Each OSI host (end system) or router (intermediate system) needs to be able to dump any of its routing tables. Routing tables may come from the: Page 7 Draft - TOOLS RFC November 9, 1992 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 via some out of band mechinism. A method must exist to pro- vide these. It is suggested that a show osi 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 via of the following network protocols: 5.3.1. SNMP Internet MIBs RFC 1238 CLNS MIB [5] NET of this router ES adjacencies, ES Connection Timer, ES hold timer IS Adjacencies 5.3.1.1. RFC IS Reachability information IS L1 Adjacencies IS L2 ADjacencies 5.3.1.2. RFC Page 8 Draft - TOOLS RFC November 9, 1992 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 5.3.2. CMIP 5.3.2.1. ISO 10733 (Network Layer Management info) [8] Network Entity Managed Object networkEntityTitles linkage-ISO9542ES-P HoldingTimerMultipler manualISSNPAAddress defaultESConfigTimer activeESConfigTimer isReachabilityChanges linkage-ISO9542IS-P holdingTimerMultiplier isConfigurationTimer suggestedESConfigurationTimer redirectHoldingTimer eSReachabilityChanges 5.3.2.2. ISO 10589 (IS-IS Management info) [9] IS Reachability information IS L1 Adjacencies IS L2 ADjacencies Page 9 Draft - TOOLS RFC November 9, 1992 5.3.2.3. ISO 10747 (IDRP Management info) [4] 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 Page 10 Draft - TOOLS RFC November 9, 1992 6. 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] R. Hagens and C.Wittbrodt, "An Echo Function for ISO 8473", Request For Comment #1139-Revised, October 1992. DDN Network Information Center, SRI International. [4] ISO/IEC DIS 10747 Information Processing Sys- tems - Telecommunications and Information Exchange between Systems - Protocol for Exchange of Inter-domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs. [5] RFC 1238 CLNS MIB (Greg Satz) - for use with Connec- tionless Network Protocol (ISO 8473) and End system to Intermediate System Protocol (ISO 9452) [6] RFC xxx Integrated IS-IS MIB - (Chris Gunner) [7] RFC xxxx IDRP MIB (Hares) [8] ISO/IEC 10733 - Information Technology - Telecommuni- cations and Information Exchange between Systems - Elements of Management Information Relating to OSI Network Layer Standards [9] ISO/IEC 10589 - Information Processing Sys- tems - Telecommunications and Information Exchange between Systems - Protocol for Exchange of Intra-Domain Routeing Information among Intermediate Systems. Page 11