As per Relevance of the word function, we have this rfc below:
Network Working Group S.
Request for Comments: 1575 Merit/
Obsoletes: 1139 C.
Category: Standards Track Stanford University/
February 1994
An Echo Function for CLNP (ISO 8473)
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This memo defines an echo function for the connection-less
layer protocol. The mechanism that is mandated here is in the
process of being standardized by ISO as "Amendment X: Addition of
Echo function to ISO 8473" an integral part of Version 2 of ISO 8473.
Table of
Section 1. Conventions ................................. 2
Section 2. Introduction ................................ 2
Section 3. The Generic Echo Function ................... 3
Section 3.1 The Echo-Request ........................... 3
Section 3.2 The Echo-Response .......................... 3
Section 4. The Implementation Mechanism ................ 4
Section 4.1 The Echo-Request ........................... 4
Section 4.2 The Echo-Response .......................... 4
Section 5. Implementation Notes ........................ 4
Section 5.1 Discarding Packets ......................... 4
Section 5.2 Error Report Flag .......................... 4
Section 5.3 Use of the Lifetime Field .................. 5
Section 5.4 Echo-request function ...................... 5
Section 5.5 Echo-response function ..................... 6
Section 5.6 Use of the Priority Option ................. 8
Section 5.7 Use of the Source Route Option ............. 8
Section 5.8 Transmission of Multiple Echo-Requests ..... 9
Section 6. Security Considerations ..................... 9
Section 7. Authors' Addresses .......................... 9
Section 8. References .................................. 9
Hares & Wittbrodt [Page 1]
RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
1.
The following language conventions are used in the items
specification in this document
o MUST, SHALL, or MANDATORY -- the item is an
requirement of the specification
o SHOULD or RECOMMENDED -- the item should generally be
for all but exceptional circumstances
o MAY or OPTIONAL -- the item is truly optional and may
followed or ignored according to the needs of the implementor
2.
The OSI Connection-less network layer protocol (ISO 8473) defines
means for transmitting and relaying data and error protocol
units, (PDUs) or preferably, packets through an OSI internet
Unfortunately, the world that these packets travel through
imperfect. Gateways and links may fail. This memo defines an
function to be used in the debugging and testing of the OSI
layer. Hosts and routers which support the OSI network layer MUST
able to originate an echo packet as well as respond when an echo
received
Network management protocols can be used to determine the state of
gateway or link. However, since these protocols themselves utilize
protocol that may experience packet loss, it cannot be
that the network management applications can be utilized. A
mechanism in the network layer is required so that systems can
probed to determine if the lowest levels of the networking
are operating correctly. This mechanism is not intended to
with or replace network management; rather it should be viewed as
addition to the facilities offered by network management
The code-path consideration requires that the echo path through
system be identical (or very close) to the path used by normal data
An echo path must succeed and fail in unison with the normal
path or else it will not provide a useful diagnostic tool
Previous drafts describing an echo function for CLNP offered
implementation alternatives (see RFC 1139). Although
compatibility is an important consideration whenever a change is
to a protocol, it is more important at this point that the
mechanisms used on the Internet interoperate. For this reason,
memo defines one implementation mechanism (consistent with one of
previous drafts).
Hares & Wittbrodt [Page 2]
RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
3. The Generic Echo
The following section describes the echo function in a
fashion. This memo defines an echo-request entity. The function
the echo-request entity is to accept an incoming echo-request packet
perform some processing, and generate an echo-response packet.
echo implementation may be thought of as an entity that coexists
the network layer. Subsequent sections will detail
implementation mechanism
For the purposes of this memo, the term "ping" shall be used to
the act of transmitting an echo-request packet to a remote
(with the expectation that an echo-response packet will be sent
to the transmitter).
3.1. The Echo-
When a system decides to ping a remote system, an echo-request
built. All fields of the packet header are assigned normal
(see implementation specific sections for more information).
address of the system to be pinged is inserted as the
NSAP address. The rules of segmentation defined for a data (DT
packet also apply to the echo-request packet
The echo-request is switched through the network toward
destination. (An echo packet must follow the same path as CLNP
packet with the same options in the CLNP header.) Upon reaching
destination system, the packet is processed according to
processing rules. At the end of the input processing, the echo
request packet is delivered to the echo-request entity
The echo-request entity will build and dispatch the echo-
packet. This is a new packet. Except as noted below, this
packet is built using the normal construction procedures.
destination address of the echo-response packet is taken from
source address of the echo-request packet. Most options present
the echo-request packet are copied into the echo-response packet (
implementation notes for more information).
3.2. The Echo-
The entire echo-request packet is included in the data portion of
echo-response packet. This includes the echo-request packet
as well as any data that accompanies the echo-request packet.
entire echo-request packet is included in the echo-response so
fields such as the echo-request lifetime may be examined when
response is received. After the echo-response packet is built, it
transmitted toward the new destination (the original source of
Hares & Wittbrodt [Page 3]
RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
echo-request). The rules of segmentation defined for a data
also apply to the echo-response packet
The echo-response packet is relayed through the network toward
destination. (A echo response packet must follow the same path as
CLNP data packet with the same options in the CLNP header.)
reaching its destination, it is processed by the packet
function and delivered to the entity that created the echo-request
4. The Implementation
The implementation mechanism defines two new 8473 packet types:
(echo-request) and ERP (echo-response). With the exception of a
type code, these packets will be identical to the date packet
every respect
4.1. The Echo-
The type code for the echo-request packet is decimal 30.
4.2. The Echo-
The type code for the echo-response packet is decimal 31.
5. Implementation
The following notes are an integral part of memo. It is
that implementors take heed of these points
5.1. Discarding
The rules used for discarding a data packet (ISO 8473, Section 6.9 -
Section 6.10) are applied when an echo-request or echo-response
discarded
5.2. Error Report
The error report flag may be set on the echo-request packet,
echo-response packet, or both. If an echo-request is discarded,
associated error-report (ER) packet will be sent to the echo-
source address on the originating machine. If an echo-response
discarded, the associated error-report packet will be sent to
echo-response source address. In general, this will be
destination address of the echo-request entity. It should be
that the echo-request entity and the originator of the echo-
packet are not required to process error-report packets
Hares & Wittbrodt [Page 4]
RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
5.3. Use of the Lifetime
The lifetime field of the echo-request and echo-response
should be set to the value normally used for a data packet. Note
although this memo does not prohibit the generation of a packet
a smaller-than-normal lifetime field, this memo explicitly does
attempt to define a mechanism for varying the lifetime field set
the echo-response packet. This memo recommends the lifetime
that would under normal circumstances by used when sending a
packet
5.4. Echo-request
This function is invoked by system management to obtain
about the dynamic state of the Network layer with respect to (a)
reachability of specific network-entities, and (b)
characteristics of the path or paths that can be created
network-entities through the operation of Network layer
functions. When invoked, the echo-request function causes an echo
request (ERQ) packet to be created. The echo-request packet shall
constructed and processed by ISO 8473 network-entities in end
and intermediate systems in exactly the same way as the data packet
with the following caveats
a) The information available to the packet composition
(ISO 8473) consists of current state, local information,
information supplied by system management
b) The source and destination address fields of the echo-
packet shall contain, respectively, a Network entity title (NET
of the originating network-entity and a Network entity title
the destination network-entity (which may be in either an
system or an intermediate system). NOTE: A Network entity
is syntactically indistinguishable from an NSAP address.
additional information in an NSAP address, if any, beyond
which is present in a Network entity title, is relevant only
the operation of the packet decomposition function in
destination end system, and therefore is not needed for
processing of an echo-request packet (from which no N-
indication is ever produced). The fact that the source
destination address fields of the echo-request packet contain
rather than NSAP addresses therefore does not affect
processing of an echo-request packet by any network-entity
c) When an echo-request packet has reached its destination,
determined by the Header processing (call HEADER FORMAT
function in ISO 8473), the echo-response function shall
this Network Protocol Data Units (NPDU) instead of the
Hares & Wittbrodt [Page 5]
RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
decomposition function. In ISO 8473, the packet
function is like a decomposing fish on the sea shore - it takes
packet down to its bare bones and processes it
Also, it is up to each individual system whether or not
echo-request packets involves system management. One example
involving system management is the reporting reception of the
packets as some systems do with the ping packet. Some
find this of value if they are being pinged to death
d) The maximum length of the echo-request packet is equal to
maximum length of the echo-response packet minus the
length of the echo-response packet header. This ensures that
entire echo-request packet can be contained within the data
of the echo-response packet (see ISO 8473).
e) The data part of the echo-request packet may, as a
matter, contain zero or more octets with any values that
within the echo-request packet. (see (d) above for maximum
of the echo-request packet). If the first octet of data is
1000 0001, then an echo-response header is contained in the echo
request packet. The existence of this header insures that
router can formulate a standard echo-response packet
Normally, the "more segmentation" flag in the encapsulated echo
response packet header shall be zero, and the segmentation portion
the encapsulated packet shall not be included. The
length in the echo-response packet header shall be zero
If the "more segmentation" flag is set in the encapsulated echo
response packet header, then a segmentation length shall be filled
and the segmentation part of the echo-response packet header will
present in the echo-response header. This same segmentation
shall be present in the echo-response sent by the router
NOTE: However, this formulated echo-response is not required
any two systems. With a common format for an echo-request
used in an environment such as the Internet, the echo-response
may not be needed, and may in fact be unnecessary overhead
5.5. Echo-response
This function is performed by a network-entity when it has
an echo-request packet that has reached its destination,
determined by the Header format analysis function (ISO 8473
6.3) that is, an echo-request packet which contains, in
destination address field, a Network entity title that identifies
network-entity. When invoked, the echo-response function causes
Hares & Wittbrodt [Page 6]
RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
echo-response (ERP) packet to be created. The echo-response
shall be constructed and processed by ISO 8473 network-entities
end systems and intermediate systems in exactly the same way as
data packet, with the following caveats
a) The information available to the packet composition
consists of current state, local information, and
contained in the corresponding echo-request packet
b) The source address field of the echo-response packet
contain the value of the destination address field of
corresponding echo-request packet. The destination address
of the echo-response packet shall contain the value of the
address field of the corresponding echo-request packet
c) The echo-request packet, in its entirety, shall be placed
the data part of the echo-response packet. The data part of
echo-response packet shall contain only the corresponding echo
request packet
d) If the data part of the echo-request packet contains an echo
response header, the packet composition function may, but is
required to, use some or all of the information contained
to select values for the fields of the echo-response
header. In this case, however, the value of the lifetime
contained in the echo-response packet header in the echo-
packet data part must be used as the value of the lifetime
in the echo-response packet. The values of the segment length
checksum fields shall be computed by the network-entity
of the contents of those fields in the echo-response packet
in the data part of the echo-request packet
e) The options part of the echo-response packet may contain
(or none) of the options described in ISO 8473 (but see
5.7 of this RFC). The values for these options, if present,
determined by the network-entity as a local matter. They may be
but are not required to be, either identical to or derived
the corresponding options in the echo-request packet and/or
echo-response packet header contained in the data part of
echo-request packet (if present). The source routing option
the echo-response packet shall not be identical to (copied from
the source routing option in the echo-request packet header.
the recording of route option in the echo-response packet
identical to (copied from) the recording of route option in
echo-request packet header, the second octet of the
value field shall be set to the value 3.
Hares & Wittbrodt [Page 7]
RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
f) It is a local matter whether or not the destination network
entity performs the lifetime control function on an echo-
packet before performing the echo-response function.
destination network-entity shall make the same decision in
regard that it would make, as a local matter, for a data packet
accordance with ISO 8473.
5.6. Use of the Priority
The 8473 priority function indicates the relative priority
packet. 0 is normal and 14 is the highest. Packets with
values will be transmitted before lower values. The
action upon receiving a 8473 packet with the priority field set
a "LOCAL MATTER". These means, any two systems could do
differently
Hopefully, in the future, Internet routers will handle this as
priority queueing function. Some implementors consider
priority queueing function to be a cap. For example, if a
is congested, all those packets with priorities higher than 20,
will be allowed through, and those with priority less than 20
be dropped
In short, the basic function of priority has wide latitude in
ISO specification. This wide latitude of implementation needs
be narrowed for implementations within a common
environment such as the Internet. The 8473 priority function
rarely implemented in today's Internet. The transmission of
echo-request packet with a priority set may provided
results until a more wide spread deployment of the
feature in 8473 capable routers and end systems
However, if the priority function must be used it is the
value may be the value 0 - which indicates Normal priority.
most likely this value will follow the 8473 pathways
In the future, as the implementation of the priority
further Internet documents will need to deal with its
use
5.7. Use of the Source Route
Use of the source route option in ISO 8473 may cause packets
loop until their lifetime expires. For this reason, this
recommends against the use of the source route option in either
echo-request or echo-response packets. If the source route
is used to specify the route that the echo-request packet
toward its destination, this memo does not recommend the use of
Hares & Wittbrodt [Page 8]
RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
automatically generated source route on the echo-response packet
5.8. Transmission of Multiple Echo-
The echo function may be utilized by more than one process on
individual machine. The mechanism by which multiple echo-
and echo-responses are correlated between multiple processes on
single machine is a local matter and not defined by this memo
6. Security
Security issues are not discussed in this memo
7. Authors'
Susan K.
MERIT/
Internet
1075 Beal
Ann Arbor, MI 48109-2112
Phone: (313) 936-3000
EMail: skh@merit.
Cathy J.
Stanford University/
Networking
Pine Hall 115
Stanford, CA 94305
Phone: (415) 725-5481
EMail: cjw@magnolia.Stanford.
8.
[1] ISO/IEC. Protocol for Providing the Connectionless-mode
Service. International Standard 8473, ISO/IEC JTC 1,
Switzerland, 1986.
[2] Hagens, R., "An Echo Function for ISO 8473", RFC 1139, IETF-
Working Group, January 1990.
[3] ISO 8473-1993 Protocol for providing the connectionless-
network service, edition 2 (IS under preparation).
Hares & Wittbrodt [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
