Echo function for ISO 8473
RFC 1139
|
Document |
Type |
|
RFC - Proposed Standard
(January 1990; No errata)
|
|
Author |
|
Robert Hagens
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 1139 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group IETF-OSI Working Group
Request for Comments: 1139 R. Hagens
January 1990
An Echo Function for ISO 8473
Status of this Memo
This memo defines an echo function for the connection-less network
layer protocol. This memo is not intended to compete with an ISO
standard. This is a Proposed Elective Standard for the Internet.
Distribution of this memo is unlimited.
Abstract
This memo defines an echo function for the connection-less network
layer protocol. Two mechanisms are introduced that may be used to
implement the echo function. The first mechanism is recommended as
an interim solution for the Internet community. The second mechanism
will be progressed to the ANSI X3S3.3 working group for consideration
as a work item.
When an ISO standard is adopted that provides functionality similar
to that described by this memo, then this memo will become obsolete
and superceded by the ISO standard.
1. Introduction
The OSI Connection-less network layer protocol (ISO 8473) defines a
means for transmitting and relaying data and error report PDUs
through an OSI internet. Unfortunately, the world that these packets
travel through is imperfect. Gateways and links may fail. This memo
defines an echo function to be used in the debugging and testing of
the OSI network layer.
Network management protocols can be used to determine the state of a
gateway or link. However, since these protocols themselves utilize a
protocol that may experience packet loss, it cannot be guaranteed
that the network management applications can be utilized. A simple
mechanism in the network layer is required so that systems can be
probed to determine if the lowest levels of the networking software
are operating correctly. This mechanism is not intended to compete
with or replace network management; rather it should be viewed as an
addition to the facilities offered by network management.
There are three important issues to consider when defining an echo
extension to ISO 8473: complexity, code-path divergence, and backward
IETF-OSI Working Group [Page 1]
RFC 1139 An Echo Function for ISO 8473 January 1990
compatibility. The complexity of the echo facility must be kept low.
If it is not, then there is a good chance that the facility will not
be universally provided. The code-path consideration requires that
the echo path through a system is identical (or very close) to the
path used by normal data. An echo path must succeed and fail in
unison with the normal data path or else it will not provide a useful
diagnostic tool.
Backward compatibility is an important consideration whenever a
change is made to a protocol. For this reason, this memo defines two
implementation mechanisms: the short term approach and the long term
approach. The short term approach will produce echo packets that are
indistinguishable from normal data ISO 8473 PDUs. These echo packets
may be switched through ISO 8473 routers that do not implement the
echo function. The short term approach will be adopted as an
Elective Internet Standard because it is backward compatible with ISO
8473. However, due to its nature, the short term approach will never
be incorporated into future versions of ISO 8473.
The long term approach will produce echo packets that are not
compatible with the existing standard. However, the long term
approach may be acceptable by ISO as an addendum to ISO 8473. In
this event, backward compatibility will no longer be an issue. At
that juncture, the short term approach defined by this memo will be
obsolete and superseded by the ISO addendum.
2. The Generic Echo Function
The following section will describe the echo function in a generic
fashion. This memo defines an echo-request entity. The function of
the echo-request entity is to accept an incoming echo-request PDU,
perform some processing, and generate an echo-reply PDU. Depending
on the echo implementation, the echo-request entity may be thought of
as an entity that exists above the network layer, or as an entity
that co-exists with the network layer. Subsequent sections will
detail the short and long term implementation mechanisms.
For the purposes of this memo, the term "ping" shall be used to mean
the act of transmitting an echo-request PDU to a remote system (with
the expectation that an echo-reply PDU will be sent back to the
transmitter).
2.1 The Echo Request
When a system decides to ping a remote system, an echo-request is
built. All fields of the PDU header are assigned normal values
(see implementation specific sections for more information). The
Show full document text