RFC 1561 (rfc1561) - Page 3 of 25
Use of ISO CLNP in TUBA Environments
Alternative Format: Original Text Document
RFC 1561 CLNP in TUBA Environments December 1993
3. Overview of CLNP
ISO CLNP is a datagram network protocol. It provides fundamentally
the same underlying service to a transport layer as IP. CLNP provides
essentially the same maximum datagram size, and for those
circumstances where datagrams may need to traverse a network whose
maximum packet size is smaller than the size of the datagram, CLNP
provides mechanisms for fragmentation (data unit identification,
fragment/total length and offset). Like IP, a checksum computed on
the CLNP header provides a verification that the information used in
processing the CLNP datagram has been transmitted correctly, and a
lifetime control mechanism ("Time to Live") imposes a limit on the
amount of time a datagram is allowed to remain in the internet
system. As is the case in IP, a set of options provides control
functions needed or useful in some situations but unnecessary for the
most common communications.
Note that the encoding of options differs between the two protocols,
as do the means of higher level protocol identification. Note also
that CLNP and IP differ in the way header and fragment lengths are
represented, and that the granularity of lifetime control (time-to-
live) is finer in CLNP.
Some of these differences are not considered "issues", as CLNP
provides flexibility in the way that certain options may be specified
and encoded (this will facilitate the use and encoding of certain IP
options without change in syntax); others, e.g., higher level
protocol identification and timestamp, must be accommodated in a
transparent manner in this profile for correct operation of TCP and
UDP, and continued interoperability with OSI implementations. Section
4 describes how header fields of CLNP must be populated to satisfy
the needs of TCP and UDP.
Errors detected during the processing of a CLNP datagram MAY be
reported using CLNP Error Reports. Implementations of CLNP for TUBA
environments MUST be capable of processing Error Reports (this is
consistent with the 1992 edition (2) of the ISO/IEC 8473 standard).
Control messages (e.g., echo request/reply and redirect) are
similarly handled in CLNP, i.e., identified as separate network layer
packet types. The relationship between CLNP Error and Control
messages and Internet Control Message Protocol (ICMP, [7]), and
issues relating to the handling of these messages is described in
Section 5.
Piscitello