Internet DRAFT - draft-ietf-noop-osi-tools
draft-ietf-noop-osi-tools
Essential Tools for the OSI Internet
Network Working Group IETF-NOOP Working Group
INTERNET DRAFT S. Hares, C. Wittbrodt
1. Status
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of
six months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not
appropriate to use Internet Drafts as reference material or
to cite them other than as a "working draft" or "work in
progress."
Please check the I-D abstract listing contained in each
Internet Draft directory to learn the current status of this
or any other Internet Draft.
This Internet Draft 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 draft specifies the mechanism specified in RFC1139 [3].
2. Abstract
This document specifies the following three necessary tools
to debug problems in the deployment and maintenance of net-
works using ISO 8473 (CLNP):
- ping or ISO Echo function
- traceroute function which uses the ISO Echo function
- routing table dump function
These CLNS tools are the basics required for hosts and
routers for CLNS network support. It is intended that this
document specify the most basic support level required for
CLNS hosts and routers.
This document should progress along the IETF track for host
and router requirements.
March 23, 1993 Expires September 23, 1993 Page 1
Essential Tools for the OSI Internet
3. Table of Contents
Section 1 Status ...................................... 1
Section 2 Abstract .................................... 1
Section 3 Table of Contents ........................... 2
Section 4 Conventions ................................. 2
Section 5 Introduction ................................ 2
Section 6 Specification ............................... 3
Section 6.1 Ping ...................................... 3
Section 6.1.1 Protocol Support ........................ 3
Section 6.1.2 Functions supported by the ping utili-
ty ............................................... 4
Section 6.2 Traceroute ................................ 4
Section 6.2.1 Basic Traceroute ........................ 4
Section 6.2.2 Use of Partial Source route in tra-
ceroute .......................................... 6
Section 6.2.3 Information needed from a Traceroute
utility .......................................... 7
Section 6.3 OSI routing table dump .................... 7
Section 6.4 MIB variables available via SNMP .......... 8
Section 6.4.1 Summary of MIB Variables ................ 8
Section 6.4.2 ASN.1 Syntax for these MIB variables .... 8
Section 7 ISO HOST.txt format ......................... 11
Section 8 Acknowledgements ............................ 12
Section 9 Author's Addresses .......................... 12
Section 10 References ................................. 14
4. Conventions
The following language conventions are used in the items of
specification in this document:
o MUST, SHALL, or MANDATORY -- the item is an absolute
requirement of the specification.
o SHOULD or RECOMMENDED -- the item should generally be followed
for all but exceptional circumstances.
o MAY or OPTIONAL -- the item is truly optional and may be
followed or ignored according to the needs of the implementor.
5. 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 nonexistent. When
such tools existed, different implementations didn't work
together.
March 23, 1993 Expires September 23, 1993 Page 2
Essential Tools for the OSI Internet
As stated in RFC 1139 a simple network layer mechanism is
necessary to allow systems to be probed to test network
layer integrity. For the purposes of running OSI networks
the authors of this document believe that other tools are
necessary too. Other tools described below are an echo
function, a traceroute function, and a routing table dump.
What this document defines is the minimum subset of tools
that are necessary to allow for the debugging of network
problems.
6. 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 MUST 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.
6.1. Ping
6.1.1. Protocol Support
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), or
preferably packets. The two values are:
1E(hex) - for the Echo Request Selector and,
1F(hex) - for the Echo Reply Selector.
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 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 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" packet with the new type function
(Echo Request Selector), it MUST attempt to return an ISO
8473 error packet to the originating host, thus showing
March 23, 1993 Expires September 23, 1993 Page 3
Essential Tools for the OSI Internet
reachability.
6.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.
6.2. Traceroute
The CLNP trace is similar to the ping utility except that it
utilizes the "Lifetime" field in the ISO 8473 packet. Hosts
and routers that support OSI MUST also support CLNP trace.
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 packet with a value for the
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.
6.2.1. Basic Traceroute
If a ISO 8473 echo-request packet is sent with "Lifetime"
field value of 1, the first hop node (router or end system)
will return an error packet to the originator 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-assembly
If the first hop node does not support echo-request type
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 packet 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.
March 23, 1993 Expires September 23, 1993 Page 4
Essential Tools for the OSI Internet
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" 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
packet (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 packet is sent
back or (for nodes that do not have the required Echo support)
an error packet is sent back, or
- the an error packet is received with error code (B0) indicating
that a node will not pass the Echo-Reply 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 Interface
If one of these error 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.
March 23, 1993 Expires September 23, 1993 Page 5
Essential Tools for the OSI Internet
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 through the network.)
6.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 route-
ing" 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 utilize the partial source route function in the
ISO traceroute, a node must set the "source routeing" option
and "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 functioning of the
3rd party/"loose source route" traceroute is the same 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 Acceptable
These errors may indicate a problem with the "loose source
route" listed in the echo-request packet for this destina-
tion. Additional packets with the same lifetime will only
repeat this error. These errors should be reported to the
user of the traceroute function.
March 23, 1993 Expires September 23, 1993 Page 6
Essential Tools for the OSI Internet
6.2.3. Information needed from a Traceroute utility
A traceroute utility should provide the following informa-
tion to the user:
- the identity of systems that comprise the path or route
to the destination (the 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 packet received as a
response to the an echo-request packet, and
- any other error conditions encountered
by traceroute.
6.3. OSI routing table dump
Each OSI host (end system) or router (intermediate system)
MUST 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
via some out of band mechanism. A method MUST exist to pro-
vide these. A show osi routes command SHOULD 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, routing tables SHOULD be available via either
SNMP or CMIP. The specification of CMIP variables are out-
side the scope of this specification. Section 6.4 specifies
March 23, 1993 Expires September 23, 1993 Page 7
Essential Tools for the OSI Internet
the RFC 1238 MIB variables which MUST be available via SNMP.
These two variables simply allow the user to get some basic
CLNS routing information.
Please note that not all the information requested is avail-
able via the CLNS MIB. Due to this fact, it is anticipated
that additional work on a CLNS MIB will be done in the
future. When a new MIB is written, it is anticipated that
this document will be updated to include the additional MIB
variables to collect such things as the ES-IS cache.
6.4. MIB variables available via SNMP
The Simple Network Management Protocol [cf] plays an impor-
tant role in monitoring of multi-protocol, managed resources
in the Internet. By convention, SNMP is mapped onto User
Datagram Protocol (UDP, cf); 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 messages should be mapped onto an
OSI transport (cf) The following Managed Objects for the
SNMP must/should/may be supported to facilitate remote moni-
toring using the SNMP:
The Simple Network Management Protocol (SNMP) plays an
important role in monitoring of multi-protocol, managed
resources in the Internet. By convention, SNMP is mapped
onto User Datagram Protocol (UDP); however in those situa-
tions where it is not possible to communicate with an ISO
8473 managed resource using SNMP over UDP, or where communi-
cation with an ISO 8473 managed resource using SNMP/UDP is
not possible/appropriate, SNMP should be mapped onto an OSI
tranport (TP4 reference). It is RECOMMENDED that the fol-
lowing Managed Objects be supported for remoted monitoring
using SNMP:
6.4.1. Summary of MIB Variables
RFC 1238 CLNS MIB[5]
1) clnpAddrTable - Addresses for Interfaces
2) clnpRoutingTable - ISO routes in system routing table.
6.4.2. ASN.1 Syntax for these MIB variables
The ASN.1 sytnax for the two variables the MIB in CLNS MIB
(RFC 1238) is included below for easy reference. Both these
RFCs remain the authoritative source for the MIB
March 23, 1993 Expires September 23, 1993 Page 8
Essential Tools for the OSI Internet
definitions.
1) clnpAddrTable
clnpAddrTable OBJECT-TYPE
object.id = .... {clnp 21 } (Dave what do I put here??)
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); #
Descriptions of Table entry values:
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.
March 23, 1993 Expires September 23, 1993 Page 9
Essential Tools for the OSI Internet
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
March 23, 1993 Expires September 23, 1993 Page 10
Essential Tools for the OSI Internet
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
}
7. ISO HOST.txt format
The OSI format for addresses allows addresses to be 20
bytes. In the long term, a Directory service (DNS service
or OSI Directory service (X.500)), will provide a host name
to address mapping. The process of getting OSI capable DNS
and Directory service may require OSI pathway to already be
set-up. Most host and router system use a fixed table to
provide this name to NSAP address mapping in order to get
OSI working on their system. The current operational problem
is each implementation has a different format. This docu-
ment defines a fixed format so that these initial name to
NSAP mapping files can be shared through-out the internet.
To conform to this document, a host or router supporting
CLNS MUST have support a "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 applica-
tions, other fields may be defined but the definition of
these is outside the scope of this specification.
OSI applications may use another file name for osi address
information. We strongly RECOMMEND that NSAP addresses in
any osi address information use the format below. This host
name to NSAP mapping MUST BE available for use by the fol-
lowing utilities on CLNS hosts and routers:
- ISO Echo (Ping) function,
- ISO traceroute function, and
- router table look-up for CLNS
routing information
We RECOMMEND that host and router systems also support a
NSAP to name mapping by the Domain Name Service Directory or
or the OSI Directory service (X.500).
March 23, 1993 Expires September 23, 1993 Page 11
Essential Tools for the OSI Internet
Format of 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>.
..... <18th octet> <19th octet> .<20th octet>
comments on the above format:
The NSAP octets should be expressed in hexidecimal. The dots
are aids to help read the NSAP address, and not required for
an NSAP address parsing. However, each NSAP address file
MUST be able to have the ability to handle the insertion of
dots.
An example of this use in the GOSIP format is:
47.0005.80ff.ff00.0000.0001.0001.0a0b.0c0d.0204.00
An example of this format in ANSI format is:
39.480f.8000.0500.0000.0001.0001.0a0b0c0d.0204.00
This value quickly shows the AFI and the NSEL octets on either end.
<name1> <name2> <name> - Indicates a sequence of name associated with
this nsap address.
8. Acknowledgements
The authors would like to acknowledge the contributions made
by Dave Piscitello. He not only kept the document accurate,
but also helped us to get rid of the ISO jargon and make the
document more readable. Thanks to Paulina Knibbe for her
work with the host.txt format. We would also like to thank
members of the Network OSI Operations Working Group of the
IETF for their comments.
9. Author's Addresses
March 23, 1993 Expires September 23, 1993 Page 12
Essential Tools for the OSI Internet
Susan K. Hares
MERIT/NSFNET
Internet Engineering
1075 Beal Avenue
Ann Arbor, MI 48109-2112
(313) 936-3000
Cathy J. Wittbrodt
Stanford University/BARRNet
Networking Systems
Pine Hall 115
Stanford, CA 94305
(415) 725-5481
March 23, 1993 Expires September 23, 1993 Page 13
Essential Tools for the OSI Internet
10. 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] S.Hares and C.Wittbrodt, "An Echo Function for ISO
8473", Internet Draft, October 1992. DDN Network Infor-
mation 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 packets.
[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)
March 23, 1993 Expires September 23, 1993 Page 14
