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