doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc1561.txt b/doc/rfc/rfc1561.txt
new file mode 100644
index 0000000..f4b9c22
--- /dev/null
+++ b/doc/rfc/rfc1561.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group                                      D. Piscitello
+Request for Comments: 1561                               Core Competence
+Category: Experimental                                     December 1993
+
+
+                  Use of ISO CLNP in TUBA Environments
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo specifies a profile of the ISO/IEC 8473 Connectionless-mode
+   Network Layer Protocol (CLNP, [1]) for use in conjunction with RFC
+   1347, TCP/UDP over Bigger Addresses (TUBA, [2]).  It describes the
+   use of CLNP to provide the lower-level service expected by
+   Transmission Control Protocol (TCP, [3]) and User Datagram Protocol
+   (UDP, [4]).  CLNP provides essentially the same datagram service as
+   Internet Protocol (IP, [5]), but offers a means of conveying bigger
+   network addresses (with additional structure, to aid routing).
+
+   While the protocols offer nearly the same services, IP and CLNP are
+   not identical. This document describes a means of preserving the
+   semantics of IP information that is absent from CLNP while preserving
+   consistency between the use of CLNP in Internet and OSI environments.
+   This maximizes the use of already-deployed CLNP implementations.
+
+Acknowledgments
+
+   Many thanks to Ross Callon (Wellfleet Communications), John Curran
+   (BBN), Cyndi Jung (3Com), Paul Brooks (UNSW), Brian Carpenter (CERN),
+   Keith Sklower (Cal Berkeley), Dino Farinacci and Dave Katz (Cisco
+   Systems), Rich Colella (NIST/CSL) and David Oran (DEC) for their
+   assistance in composing this text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Piscitello                                                      [Page 1]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+Conventions
+
+   The following language conventions are used in the items of
+   specification in this document:
+
+         * MUST, SHALL, or MANDATORY -- the item is an absolute
+           requirement of the specification.
+
+         * SHOULD or RECOMMENDED -- the item should generally be
+           followed for all but exceptional circumstances.
+
+         * MAY or OPTIONAL -- the item is truly optional and may be
+           followed or ignored according to the needs of the
+           implementor.
+
+1.  Terminology
+
+   To the extent possible, this document is written in the language of
+   the Internet. For example, packet is used rather than "protocol data
+   unit", and "fragment" is used rather than "segment".  There are some
+   terms that carry over from OSI; these are, for the most part, used so
+   that cross-reference between this document and RFC 994 [6] or ISO/IEC
+   8473 is not entirely painful.  OSI acronyms are for the most part
+   avoided.
+
+2.  Introduction
+
+   The goal of this specification is to allow compatible and
+   interoperable implementations to encapsulate TCP and UDP packets in
+   CLNP data units. In a sense, it is more of a "hosts requirements"
+   document for the network layer of TUBA implementations than a
+   protocol specification. It is assumed that readers are familiar with
+   STD 5, RFC 791, STD 5, RFC 792 [7], STD 3, RFC 1122 [8], and, to a
+   lesser extent, RFC 994 and ISO/IEC 8473.  This document is compatible
+   with (although more restrictive than) ISO/IEC 8473; specifically, the
+   order, semantics, and processing of CLNP header fields is consistent
+   between this and ISO/IEC 8473.
+
+   [Note: RFC 994 contains the Draft International Standard version of
+   ISO CLNP, in ASCII text. This is not the final version of the ISO/IEC
+   protocol specification; however, it should provide sufficient
+   background for the purpose of understanding the relationship of CLNP
+   to IP, and the means whereby IP information is to be encoded in CLNP
+   header fields. Postscript versions of ISO CLNP and associated routing
+   protocols are available via anonymous FTP from merit.edu, and may be
+   found in the directory /pub/ISO/IEC.
+
+
+
+
+
+Piscitello                                                      [Page 2]
+
+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                                                      [Page 3]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+   Table 1 provides a high-level comparison of CLNP to IP:
+
+ Function              | ISO CLNP               | DOD IP
+ ----------------------|------------------------|-----------------------
+ Header Length         | indicated in octets    | in 32-bit words
+ Version Identifier    | 1 octet                | 4 bits
+ Lifetime (TTL)        | 500 msec units         | 1 sec units
+ Flags                 | Fragmentation allowed, | Don't Fragment,
+                       | More Fragments         | More Fragments,
+                       | Suppress Error Reports | <not defined>
+ Packet Type           | 5 bits                 | <not defined>
+ Fragment Length       | 16 bits, in octets     | 16 bits, in octets
+ Header Checksum       | 16-bit (Fletcher)      | 16-bit
+ Total Length          | 16 bits, in octets     | <not defined>
+ Addressing            | Variable length        | 32-bit fixed
+ Data Unit Identifier  | 16 bits                | 16 bits
+ Fragment offset       | 16 bits, in octets     | 13 bits, 8-octet units
+ Higher Layer Protocol | Selector in address    | Protocol
+ Options               | Security               | Security
+                       | Priority               | TOS Precedence bits
+                       | Complete Source Route  | Strict Source Route
+                       | Quality of Service     | Type of Service
+                       | Partial Source Route   | Loose Source Route
+                       | Record Route           | Record Route
+                       | Padding                | Padding
+                       | <defined herein>       | Timestamp
+
+                 Table 1. Comparison of IP to CLNP
+
+   The composition and processing of a TCP pseudo-header when CLNP is
+   used to provide the lower-level service expected by TCP and UDP is
+   described in Section 6.
+
+   [Note: This experimental RFC does not discuss multicasting.
+   Presently, there are proposals for multicast extensions for CLNP in
+   ISO/IEC/JTC1/SC6, and a parallel effort within TUBA. A future
+   revision to this RFC will incorporate any extensions to CLNP that may
+   be introduced as a result of the adoption of one of these
+   alternatives.]
+
+
+
+
+
+
+
+
+
+
+
+
+Piscitello                                                      [Page 4]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+4.  Proposed Internet Header using CLNP
+
+   A summary of the contents of the CLNP header, as it is proposed for
+   use in TUBA environments, is illustrated in Figure 4-1:
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |        ........Data Link Header........       | NLP ID        |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |Header Length  |     Version   | Lifetime (TTL)|Flags|  Type   |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |        Fragment Length        |           Checksum            |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  | Dest Addr Len |               Destination Address...          |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |               ... Destination Address...                      |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |               ... Destination Address...                      |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |               ... Destination Address...                      |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |               ... Destination Address...                      |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  | PROTO field   | Src  Addr Len |  Source  Address...           |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |               ... Source Address...                           |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |               ... Source Address...                           |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |               ... Source Address...                           |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |               ... Source Address...                           |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |Source Address |   Reserved    |       Data Unit Identifier    |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |         Fragment Offset       |   Total Length of packet      |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |                   Options  (see Table 1)                      |
+  |                                                               |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |                               Data                            |
+  |                                                               |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+         Note that each tick mark represents one bit position.
+
+                     Figure 4-1. CLNP for TUBA
+
+
+
+Piscitello                                                      [Page 5]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+  Note 1: For illustrative purposes, Figure 4-1 shows Destination
+          and Source Addresses having a length of 19 octets,
+          including the PROTO/reserved field. In general, addresses
+          can be variable length, up to a maximum of 20 octets,
+          including the PROTO/reserved field.
+
+  Note 2: Due to differences in link layer protocols, it is not
+          possible to ensure that the packet starts on an even
+          alignment. Note, however, that many link level protocols
+          over which CLNP is operated use a odd length link
+          (e.g., IEEE 802.2). (In Figure 4-1, the rest of the CLNP
+          packet is even-aligned.)
+
+   The encoding of CLNP fields for use in TUBA environments is as
+   follows.
+
+4.1  Network Layer Protocol Identification (NLP ID)
+
+   This one-octet field identifies this as the ISO/IEC 8473 protocol; it
+   MUST set to binary 1000 0001.
+
+4.2  Header Length Indication (Header Length)
+
+   Header Length is the length of the CLNP header in octets, and thus
+   points to the beginning of the data. The value 255 is reserved. The
+   header length is the same for all fragments of the same (original)
+   CLNP packet.
+
+4.3  Version
+
+   This one-octet field identifies the version of the protocol; it MUST
+   be set to a binary value 0000 0001.
+
+4.4  Lifetime (TTL)
+
+   Like the TTL field of IP, this field indicates the maximum time the
+   datagram is allowed to remain in the internet system.  If this field
+   contains the value zero, then the datagram MUST be destroyed; a host,
+   however, MUST NOT send a datagram with a lifetime value of zero.
+   This field is modified in internet header processing.  The time is
+   measured in units of 500 milliseconds, but since every module that
+   processes a datagram MUST decrease the TTL by at least one even if it
+   process the datagram in less than 500 millisecond, the TTL must be
+   thought of only as an upper bound on the time a datagram may exist.
+   The intention is to cause undeliverable datagrams to be discarded,
+   and to bound the maximum CLNP datagram lifetime. [Like IP, the
+   colloquial usage of TTL in CLNP is as a coarse hop-count.]
+
+
+
+
+Piscitello                                                      [Page 6]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+   Unless otherwise directed, a host SHOULD use a value of 255 as the
+   initial lifetime value.
+
+4.5  Flags
+
+   Three flags are defined. These occupy bits 0, 1, and 2 of the
+   Flags/Type octet:
+
+                          0   1   2
+                        +---+---+---+
+                        | F | M | E |
+                        | P | F | R |
+                        +---+---+---+
+
+   The Fragmentation Permitted (FP) flag, when set to a value of one
+   (1), is semantically equivalent to the "may fragment" value of the
+   Don't Fragment field of IP; similarly, when set to zero (0), the
+   Fragmentation Permitted flag is semantically equivalent to the "Don't
+   Fragment" value of the Don't Fragment Flag of IP.
+
+   [Note: If the Fragmentation Permitted field is set to the value 0,
+   then the Data Unit Identifier, Fragment Offset, and Total Length
+   fields are not present. This denotes a single fragment datagram. In
+   such datagrams, the Fragment Length field contains the total length
+   of the datagram.]
+
+   The More Fragments flag of CLNP is semantically and syntactically the
+   same as the More Fragments flag of IP; a value of one (1) indicates
+   that more segments/fragments are forthcoming; a value of zero (0)
+   indicates that the last octet of the original packet is present in
+   this segment.
+
+   The Error Report (ER) flag is used to suppress the generation of an
+   error message by a host/router that detects an error during the
+   processing of a CLNP datagram; a value of one (1) indicates that the
+   host that originated this datagram thinks error reports are useful,
+   and would dearly love to receive one if a host/router finds it
+   necessary to discard its datagram(s).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Piscitello                                                      [Page 7]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+4.6  Type field
+
+   The type field distinguishes data CLNP packets from Error Reports
+   from Echo packets. The following values of the type field apply:
+
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   |   flags   | 1 | 1 | 1 | 0 | 0 |  => Encoding of Type = data packet
+   +---+---+---+---+---+---+---+---+
+   |   flags   | 0 | 0 | 0 | 0 | 1 |  => Encoding of Type = error report
+   +---+---+---+---+---+---+---+---+
+   |   flags   | 1 | 1 | 1 | 1 | 0 |  => Encoding of Type = echo request
+   +---+---+---+---+---+---+---+---+
+   |   flags   | 1 | 1 | 1 | 1 | 1 |  => Encoding of Type = echo reply
+   +---+---+---+---+---+---+---+---+
+
+   Error Report packets are described in Section 5.
+
+   Echo packets and their use are described in RFC 1139 [9].
+
+4.7  Fragment Length
+
+   Like the Total Length of the IP header, the Fragment length field
+   contains the length in octets of the fragment (i.e., this datagram)
+   including both header and data.
+
+   [Note: CLNP also may also have a Total Length field, that contains
+   the length of the original datagram; i.e., the sum of the length of
+   the CLNP header plus the length of the data submitted by the higher
+   level protocol, e.g., TCP or UDP. See Section 4.12.]
+
+4.8  Checksum
+
+   A checksum is computed on the header only. It MUST be verified at
+   each host/router that processes the packet; if header fields are
+   changed during processing (e.g., the Lifetime), the checksum is
+   modified. If the checksum is not used, this field MUST be coded with
+   a value of zero (0). See Appendix A for algorithms used in the
+   computation and adjustment of the checksum. Readers are encouraged to
+   see [10] for a description of an efficient implementation of the
+   checksum algorithm.
+
+4.9  Addressing
+
+   CLNP uses OSI network service access point addresses (NSAPAs); NSAPAs
+   serve the same identification and location functions as an IP
+   address, plus the protocol selector value encoded in the IPv4
+   datagram header, and  with additional hierarchy.  General purpose
+
+
+
+Piscitello                                                      [Page 8]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+   CLNP implementations MUST handle NSAP addresses of variable length up
+   to 20 octets, as defined in ISO/IEC 8348 [11]. TUBA implementations,
+   especially routers, MUST accommodate these as well. Thus, for
+   compatibility and interoperability with OSI use of CLNP, the initial
+   octet of the Destination Address is assumed to be an Authority and
+   Format Indicator, as defined in ISO/IEC 8348. NSAP addresses may be
+   between 8 and 20 octets long (inclusive).
+
+   TUBA implementations MUST support both ANSI and GOSIP style
+   addresses; these are described in RFC 1237 [12], and illustrated in
+   Figure 4-2.  RFC 1237 describes the ANSI/GOSIP initial domain parts
+   as well as the format and composition of the domain specific part. It
+   is further recommended that TUBA implementations support the
+   assignment of system identifiers for TUBA/CLNP hosts defined in [13]
+   for the purposes of host address autoconfiguration as described in
+   [14]. Additional considerations specific to the interpretation and
+   encoding of the selector part are described in sections 4.9.2 and
+   4.9.4.
+
+            +-------------+
+            | <-- IDP --> |
+            +----+--------+----------------------------------+
+            |AFI |  IDI   |           <-- DSP -->            |
+            +----+--------+----+---+-----+----+-----+---+----+
+            | 47 |  0005  |DFI |AA |Rsvd | RD |Area |ID |Sel |
+            +----+--------+----+---+-----+----+-----+---+----+
+     octets | 1  |   2    | 1  | 3 |  2  | 2  | 2   | 6 | 1  |
+            +----+--------+----+---+-----+----+-----+---+----+
+
+                 Figure 4-2 (a): GOSIP Version 2 NSAP structure.
+
+            +-------------+
+            |<-- IDP -->  |
+            +----+--------+----------------------------------+
+            |AFI |  IDI   |          <-- DSP -->             |
+            +----+--------+----+---+-----+----+-----+---+----+
+            | 39 |  840   |DFI |ORG|Rsvd | RD |Area |ID |Sel |
+            +----+--------+----+---+-----+----+-----+---+----+
+     octets | 1  |   2    | 1  | 3 |  2  | 2  |  2  | 6 | 1  |
+            +----+--------+----+---+-----+----+-----+---+----+
+
+             Figure 4-2 (b): ANSI NSAP address format for DCC=840
+
+
+
+
+
+
+
+
+
+Piscitello                                                      [Page 9]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+        Definitions:
+                     IDP   Initial Domain Part
+                     AFI   Authority and Format Identifier
+                     IDI   Initial Domain Identifier
+                     DSP   Domain Specific Part
+                     DFI   DSP Format Identifier
+                     AA    Administration Authority
+                     ORG   Organization Name (numeric form)
+                     Rsvd  Reserved
+                     RD    Routing Domain Identifier
+                     Area  Area Identifier
+                     ID    System Identifier
+                     Sel   NSAP Selector
+
+4.9.1  Destination Address Length Indicator
+
+   This field indicates the length, in octets, of the Destination
+   Address.
+
+4.9.2  Destination Address
+
+   This field contains an OSI NSAP address, as described in Section 4.9.
+   It MUST always contain the address of the final destination. (This is
+   true even for packets containing a source route option, see Section
+   4.13.4).
+
+   The final octet of the destination address MUST always contain the
+   value of the PROTO field, as defined in IP.  The 8-bit PROTO field
+   indicates the next level protocol used in the data portion of the
+   CLNP datagram.  The values for various protocols are specified in
+   "Assigned Numbers" [15]. For the PROTO field, the value of zero (0)
+   is reserved.
+
+   TUBA implementations that support TCP/UDP as well as OSI MUST use the
+   protocol value (1Dh, Internet decimal 29) reserved for ISO transport
+   protocol class 4.
+
+4.9.3  Source Address Length Indicator
+
+   This field indicates the length, in octets, of the Source Address.
+
+4.9.4  Source Address
+
+   This field contains an OSI NSAP address, as described in Section 4.9.
+
+   The final octet of the source address is reserved. It MAY be set to
+   the protocol field value on transmission, and shall be ignored on
+   reception (the value of zero MUST not be used).
+
+
+
+Piscitello                                                     [Page 10]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+4.10  Data Unit Identifier
+
+   Like the Identification field of IP, this 16-bit field is used to
+   distinguish segments of the same (original) packet for the purposes
+   of reassembly. This field is present when the fragmentation permitted
+   flag is set to one.
+
+4.11  Fragment Offset
+
+   Like the Fragment Offset of IP, this 16-bit is used to identify the
+   relative octet position of the data in this fragment with respect to
+   the start of the data submitted to CLNP; i.e., it indicates where in
+   the original datagram this fragment belongs.  The offset is measured
+   in octets; the value of this field shall always be a multiple of
+   eight (8). This field is present when the fragmentation permitted
+   flag is set to one.
+
+4.12  Total Length
+
+   The total length of the CLNP packet in octets is determined by the
+   originator and placed in the Total Length field of the header. The
+   Total Length field specifies the entire length of the original
+   datagram, including both the header and data. This field MUST NOT be
+   changed in any fragment of the original packet for the duration of
+   the packet lifetime. This field is present when the fragmentation
+   permitted flag is set to one.
+
+4.13  Options
+
+   All CLNP options are "triplets" of the form <parameter code>,
+   <parameter length>, and <parameter value>.  Both the parameter code
+   and length fields are always one octet long; the length parameter
+   value, in octets, is indicated in the parameter length field. The
+   following options are defined for CLNP for TUBA.
+
+4.13.1  Security
+
+   The value of the parameter code field is binary 1100 0101. The length
+   field MUST be set to the length of a Basic (and Extended) Security IP
+   option(s) as identified in RFC 1108 [16], plus 1.  Octet 1 of the
+   security parameter value field -- the CLNP Security Format Code -- is
+   set to a binary value 0100 0000, indicating that the remaining octets
+   of the security field contain either the Basic or Basic and Extended
+   Security options as identified in RFC 1108. This encoding points to
+   the administration of the source address (e.g., ISOC) as the
+   administration of the security option; it is thus distinguished from
+   the globally unique format whose definition is reserved for OSI use.
+   Implementations wishing to use a security option MUST examine the
+
+
+
+Piscitello                                                     [Page 11]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+   PROTO field in the source address; if the value of PROTO indicates
+   the CLNP client is TCP or UDP, the security option described in RFC
+   1108 is used.
+
+   [Note: If IP options change, TUBA implementations MUST follow the new
+   recommendations. This RFC, or revisions thereof, must document the
+   new recommendations to assure compatibility.]
+
+   The formats of the Security option, encoded as a CLNP option, is as
+   follows. The CLNP option will be used to convey the Basic and
+   Extended Security options as sub-options; i.e., the exact encoding of
+   the Basic/Extended Security IP Option is carried in a single CLNP
+   Security Option, with the length of the CLNP Security option
+   reflecting the sum of the lengths of the Basic and Extended Security
+   IP Option.
+
+   +--------+--------+--------+--------+--------+---//----+-
+   |11000100|XXXXXXXX|01000000|10000010|YYYYYYYY|         |      ...
+   +--------+--------+--------+--------+--------+---//----+----
+    CLNP       CLNP     CLNP     BASIC   BASIC    BASIC
+    OPTION    OPTION   FORMAT  SECURITY  OPTION   OPTION
+    TYPE      LENGTH    CODE    TYPE     LENGTH   VALUE
+    (197)                       (130)
+
+                          ---+------------+------------+----//-------+
+                     ...     |  10000101  |  000LLLLL  |             |
+                        -----+------------+------------+----//-------+
+                                EXTENDED     EXTENDED    EXTENDED OPTION
+                                OPTION       OPTION          VALUE
+                               TYPE (133)    LENGTH
+
+   The syntax, semantics and  processing of the Basic and Extended IP
+   Security Options are defined in RFC 1108.
+
+4.13.2  Type of Service
+
+   [Note: Early drafts recommended the use of IP Type of Service as
+   specified in RFC 1349. There now appears to be a broad consensus that
+   this encoding is insufficient, and there is renewed interest in
+   exploring the utility of the "congestion experienced" flag available
+   in the CLNP QOS Maintenance option. This RFC thus recommends the use
+   of the QOS Maintenance option native to CLNP.]
+
+   The Quality of Service Maintenance option allows the originator of a
+   CLNP datagram to convey information about the quality of service
+   requested by the originating upper layer process. Routers MAY use
+   this information as an aid in selecting a route when more than one
+   route satisfying other routing criteria is available and the
+
+
+
+Piscitello                                                     [Page 12]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+   available routes are know to differ with respect to the following
+   qualities of service: ability to preserve sequence, transit delay,
+   cost, residual error probability. Through this option, a router may
+   also indicate that it is experiencing congestion.
+
+   The encoding of this option is as follows:
+
+      +-----------+-----------+----------+
+      | 1100 0011 | 0000 0001 | 110ABCDE |
+      +-----------+-----------+----------+
+       CLNP QOS     OPTION      QOS FLAGS
+       TYPE (195)   LENGTH
+
+   The value of the parameter code field MUST be set to a value of
+   binary 1100 0011 (the CLNP Quality of Service Option Code point).
+   The length field MUST be set to one (1).
+
+   Bits 8-6 MUST be set as indicated in the figure. The flags "ABCDE"
+   are interpreted as follows:
+
+         A=1  choose path that maintains sequence over
+              one that minimizes transit delay
+         A=0  choose path that minimizes transit delay over
+              one that maintains sequence
+         B=1  congestion experienced
+         B=0  no congestion to report
+         C=1  choose path that minimizes transit delay over
+              over low cost
+         C=0  choose low cost over path that
+              minimizes transit delay
+         D=1  choose pathe with low residual error probability over
+              one that minimizes transit delay
+         D=0  choose path that minimizes transit delay over
+              one with low residual error probability
+         E=1  choose path with low residual error probability over
+              low cost
+         E=0  choose path with low cost over one with low
+              residual error probability
+
+4.13.3  Padding
+
+   The padding field is used to lengthen the packet header to a
+   convenient size. The parameter code field MUST be set to a value of
+   binary 1100 1100. The value of the  parameter length field is
+   variable. The parameter value MAY contain any value; the contents of
+   padding fields MUST be ignored by the receiver.
+
+
+
+
+
+Piscitello                                                     [Page 13]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+      +----------+----------+-----------+
+      | 11001100 | LLLLLLLL | VVVV VVVV |
+      +----------+----------+-----------+
+
+4.13.4  Source Routing
+
+   Like the strict source route option of IP, the Complete Source Route
+   option of CLNP is used to specify the exact and entire route an
+   internet datagram MUST take. Similarly, the Partial Source Route
+   option of CLNP provides the equivalent of the loose source route
+   option of IP; i.e., a means for the source of an internet datagram to
+   supply (some) routing information to be used by gateways in
+   forwarding the internet datagram towards its destination. The
+   identifiers encoded in this option are network entity titles, which
+   are semantically and syntactically the same as NSAPAs and which can
+   be used to unambiguously identify a network entity in an intermediate
+   system (router).
+
+   The parameter code for Source Routing is binary 1100 1000. The length
+   of the source routing parameter value is variable.
+
+   The first octet of the parameter value is a type code, indicating
+   Complete Source Routing (binary 0000 0001) or Partial Source Routing
+   (binary 0000 0000). The second octet identifies the offset of the
+   next network entity title to be processed in the list, relative to
+   the start of the parameter (i.e., a value of 3 is used to identify
+   the first address in the list). The offset value is modified by each
+   router using a complete source route or by each listed router using a
+   partial source route to point to the next NET.
+
+   The third octet begins the list of network entity titles. Only the
+   NETs of intermediate systems are included in the list; the source and
+   destination addresses shall not be included.  The list consists of
+   variable length network entity title entries; the first octet of each
+   entry gives the length of the network entity title that comprises the
+   remainder of the entry.
+
+4.13.5  Record Route
+
+   Like the IP record route option, the Record route option of CLNP is
+   used to trace the route a CLNP datagram takes.  A recorded route
+   consists of a list of network entity titles (see Source Routing). The
+   list is constructed as the CLNP datagram is forwarded along a path
+   towards its final destination. Only titles of intermediate systems
+   (routers) that processed the datagram are included in the recorded
+   route; the network entity title of the originator of the datagram
+   SHALL NOT be recorded in the list.
+
+
+
+
+Piscitello                                                     [Page 14]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+   The parameter code for Record Route is binary 1100 1011. The length
+   of the record route parameter value is variable.
+
+   The first octet of the parameter value is a type code, indicating
+   Complete Recording of Route (0000 0001) or Partial Recording of Route
+   (0000 0000). When complete recording of route is selected, reassembly
+   at intermediate systems MAY be performed only when all fragments of a
+   given datagram followed the same route; partial recording of route
+   eliminates or "loosens" this constraint.
+
+   The second octet identifies the offset where the next network entity
+   title entry (see Source Routing) MAY be recorded (i.e., the end of
+   the current list), relative to the start of the parameter.  A value
+   of 3 is used to identify the initial recording position. The process
+   of recording a network entity title entry is as follows. A router
+   adds the length of its network entity title entry to the value of
+   record route offset and compares this new value to the record route
+   list length indicator; if the value does not exceed the length of the
+   list, entity title entry is recorded, and the offset value is
+   incremented by the value of the length of the network entity title
+   entry. Otherwise, the recording of route is terminated, and the
+   router MUST not record its network entity title in the option. If
+   recording of route has been terminated, this (second) octet has a
+   value 255.
+
+   The third octet begins the list of network entity titles.
+
+4.13.6  Timestamp
+
+   [Note: There is no timestamp option in edition 1 of ISO/IEC 8473, but
+   the option has been proposed and submitted to ISO/IEC JTC1/SC6.]
+
+   The parameter code value 1110 1110 is used to identify the Timestamp
+   option; the syntax and semantics of Timestamp are identical to that
+   defined in IP.
+
+   The Timestamp Option is defined in STD 5, RFC 791. The CLNP parameter
+   code 1110 1110 is used rather than the option type code 68 to
+   identify the Timestamp option, and  the parameter value conveys the
+   option length. Octet 1 of the Timestamp parameter value shall be
+   encoded as the pointer (octet 3 of IP Timestamp); octet 2 of the
+   parameter value shall be encoded as the overflow/format octet (octet
+   4 of IP Timestamp); the remaining octets shall be used to encode the
+   timestamp list. The size is fixed by the source, and cannot be
+   changed to accommodate additional timestamp information.
+
+
+
+
+
+
+Piscitello                                                     [Page 15]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+        +--------+--------+--------+--------+
+        |11101110| length | pointer|oflw|flg|
+        +--------+--------+--------+--------+
+        |         network entity title      |
+        +--------+--------+--------+--------+
+        |             timestamp             |
+        +--------+--------+--------+--------+
+        |                 .                 |
+                          .
+
+5.  Error Reporting and Control Message Handling
+
+   CLNP and IP  differ in the way in which errors are reported to hosts.
+   In IP environments, the Internet Control Message Protocol (ICMP, [7])
+   is used to return (error) messages to hosts that originate packets
+   that cannot be processed. ICMP messages are transmitted as user data
+   in IP datagrams. Unreachable destinations, incorrectly composed IP
+   datagram headers, IP datagram discards due to congestion, and
+   lifetime/reassembly time exceeded are reported; the complete internet
+   header that caused the error plus (at least) 8 octets of the segment
+   contained in that IP datagram are returned to the sender as part of
+   the ICMP error message. For certain errors, e.g., incorrectly
+   composed IP datagram headers, the specific octet which caused the
+   problem is identified.
+
+   In CLNP environments, an unique message type, the Error Report type,
+   is used in the network layer protocol header to distinguish Error
+   Reports from CLNP datagrams. CLNP Error Reports are generated on
+   detection of the same types of errors as with ICMP.  Like ICMP error
+   messages, the complete CLNP header that caused the error is returned
+   to the sender in the data portion of the Error Report.
+   Implementations SHOULD return at least 8 octets of the datagram
+   contained in the CLNP datagram to the sender of the original CLNP
+   datagram. Here too, for certain errors, the specific octet which
+   caused the problem is identified.
+
+   A summary of the contents of the CLNP Error Report, as it is proposed
+   for use in TUBA environments, is illustrated in Figure 5-1:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Piscitello                                                     [Page 16]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        ........Data Link Header........       | NLP ID        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Header Length  |     Version   | Lifetime (TTL)| 000 | Type=ER |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  TOTAL Length of Error Report |           Checksum            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Dest Addr Len |               Destination Address...          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Destination Address...                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Destination Address...                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Destination Address...                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Destination Address...                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | PROTO field   | Src  Addr Len |  Source  Address...           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Source Address...                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Source Address...                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Source Address...                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Source Address...                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       ... Source Address      | Reason for Discard (type/len) |
+   |                               |   1100 0001   | 0000 0010     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Reason for Discard        |    Options...                 |
+   |   code        |   pointer     |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           Options                             |
+   :                                                               :
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            Data                               |
+   :                                                               :
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+             Note that each tick mark represents one bit position.
+
+                      Figure 5-1. Error Report Format
+
+
+
+
+Piscitello                                                     [Page 17]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+5.1  Rules for processing an Error Report
+
+   The following is a summary of the rules for processing an Error
+   Report:
+
+         * An Error Report is not generated to report a problem
+           encountered while processing an Error Report.
+
+         * Error Reports MAY NOT be fragmented (hence, the
+           fragmentation part is absent).
+
+         * The Reason for Discard Code field is populated with one of
+           the values from Table 5-1.
+
+         * The Pointer field is populated with number of the first
+           octet of the field that caused the Error Report to be
+           generated. If it is not possible to identify the offending
+           octet, this field MUST be zeroed.
+
+         * If the Priority or Type of Service option is present in the
+           errored datagram, the Error Report MUST specify the same
+           option, using the value specified in the original datagram.
+
+         * If the Security option is present in the errored datagram,
+           the Error Report MUST specify the same option, using the
+           value specified in the original datagram; if the Security
+           option is not supported by the intermediate system, no Error
+           Report is to be generated (i.e., "silently discard" the
+           received datagram).
+
+         * If the Complete Source Route option is specified in the
+           errored datagram, the Error Report MUST compose a reverse of
+           that route, and return the datagram along the same path.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Piscitello                                                     [Page 18]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+5.2  Comparison of ICMP and CLNP Error Messages
+
+   Table 5-1 provides a loose comparison of ICMP message types and codes
+   to CLNP Error Type Codes (values in Internet decimal):
+
+ CLNP Error Type  Codes            | ICMP Message           (Type, Code)
+ ----------------------------------|------------------------------------
+ Reason not specified          (0) | Parameter Problem           (12, 0)
+ Protocol Procedure Error      (1) | Parameter Problem           (12, 0)
+ Incorrect Checksum            (2) | Parameter Problem           (12, 0)
+ PDU Discarded--Congestion     (3) | Source Quench                (4, 0)
+ Header Syntax Error           (4) | Parameter problem           (12, 0)
+ Need to Fragment could not    (5) | Frag needed, DF set          (3, 4)
+ Incomplete PDU received       (6) | Parameter Problem           (12, 0)
+ Duplicate Option              (7) | Parameter Problem           (12, 0)
+ Destination Unreachable     (128) | Dest Unreachable,Net unknown (3, 0)
+ Destination Unknown         (129) | Dest Unreachable,host unknown(3, 1)
+ Source Routing Error        (144) | Source Route failed          (3, 5)
+ Source Route Syntax Error   (145) | Source Route failed          (3, 5)
+ Unknown Address in Src Route(146) | Source Route failed          (3, 5)
+ Path not acceptable         (147) | Source Route failed          (3, 5)
+ Lifetime expired            (160) | TTL exceeded                (11, 0)
+ Reassembly Lifetime Expired (161) | Reassembly time exceeded    (11, 1)
+ Unsupported Option          (176) | Parameter Problem           (12, 0)
+ Unsupported Protocol Version(177) | Parameter problem           (12, 0)
+ Unsupported Security Option (178) | Parameter problem           (12, 0)
+ Unsupported Src Rte Option  (179) | Parameter problem           (12, 0)
+ Unsupported Rcrd Rte        (180) | Parameter problem           (12, 0)
+ Reassembly interference     (192) | Reassembly time exceeded    (11, 1)
+
+    Table 5-1. Comparison of CLNP Error Reports to ICMP Error Messages
+
+ Note 1: The current accepted practice for IP is that source quench
+         should not be used; if it is used, implementations MUST
+         not return a source quench packet for every relevant packet.
+         TUBA/CLNP implementations are encouraged to adhere to these
+         guidelines.
+
+ Note 2: There are no corresponding CLNP Error Report Codes for the
+         following ICMP error message types:
+         - Protocol Unreachable  (3, 2)
+         - Port Unreachable      (3, 3)
+         [Note: Additional error code points available in the ER type
+              code block can be used to identify these message types.]
+
+
+
+
+
+
+
+Piscitello                                                     [Page 19]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+6.  Pseudo-Header Considerations
+
+   A checksum is computed on UDP and TCP segments to verify the
+   integrity of the UDP/TCP segment. To further verify that the UDP/TCP
+   segment has arrived at its correct destination, a pseudo-header
+   consisting of information used in the delivery of the UDP/TCP segment
+   is composed and included in the checksum computation.
+
+   To compute the checksum on a UDP or TCP segment prior to
+   transmission, implementations MUST compose a pseudo-header to the
+   UDP/TCP segment consisting of the following information that will be
+   used when composing the CLNP datagram:
+
+         * Destination Address Length Indicator
+
+         * Destination Address (including PROTO field)
+
+         * Source Address Length Indicator
+
+         * Source Address (including Reserved field)
+
+         * A two-octet encoding of the Protocol value
+
+         * TCP/UDP segment length
+
+   If the length of the {source address length field + source address +
+   destination address field + destination address } is not an integral
+   number of octets, a trailing 0x00 nibble is padded. If GOSIP
+   compliant NSAP addresses are used, this never happens (this is known
+   as the Farinacci uncertainty principle).  The last byte in the
+   Destination Address has the value 0x06 for TCP and 0x11 for UDP, and
+   the Protocol field is encoded 0x0006 for TCP and 0x0011 for UDP.  If
+   needed, an octet of zero is added to the end of the UDP/TCP segment
+   to pad the datagram to a length that is a multiple of 16 bits.
+
+   [Note: the pseudoheader is encoded in this manner to expedite
+   processing, as it allows implementations to grab a contiguous stream
+   of octets beginning at the destination address length indicator and
+   terminating at the final octet of the source address; the PROTOCOL
+   field is present to have a consistent representation across IPv4 and
+   CLNP/TUBA implementations.]
+
+
+
+
+
+
+
+
+
+
+Piscitello                                                     [Page 20]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+   Figure 6-1 illustrates the resulting pseudo-header when both source
+   and destination addresses are maximum length.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Dest Addr Len |               Destination Address...          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Destination Address...                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Destination Address...                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Destination Address...                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Destination Address...                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    (PROTO)    | Src  Addr Len |  Source  Address...           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Source Address...                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Source Address...                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Source Address...                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               ... Source Address...                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | ...           | (Reserved)    |    Protocol                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   UDP/TCP segment length      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                           Figure 6-1. Pseudo-header
+
+7.  Security Considerations
+
+   ISO CLNP is an unreliable network datagram protocol, and is subject
+   to the same security considerations as Internet Protocol ([5], [8]);
+   methods for conveying the same security handling information
+   recommended for IP are described in Section 4.13.1, Security Option.
+
+
+
+
+
+
+
+
+
+
+
+
+Piscitello                                                     [Page 21]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+8.  Author's Address
+
+   David M. Piscitello
+   Core Competence
+   1620 Tuckerstown Road
+   Dresher, PA 19025
+
+   Phone: 215-830-0692
+   EMail: wk04464@worldlink.com
+
+9.  References
+
+   [1] ISO/IEC 8473-1992. International Standards Organization -- Data
+       Communications -- Protocol for Providing the Connectionless
+       Network Service, Edition 2.
+
+   [2] Callon, R., "TCP/UDP over Bigger Addresses (TUBA)", RFC 1347,
+       Internet Architecture Board, May 1992.
+
+   [3] Postel, J., "Transmission Control Protocol (TCP)", STD 7, RFC
+       793, USC/Information Sciences Institute, September 1981.
+
+   [4] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768,
+       USC/Information Sciences Institute, September 1981.
+
+   [5] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791,
+       USC/Information Sciences Institute, September 1981.
+
+   [6] Chapin, L., "ISO DIS 8473, Protocol for Providing the
+       Connectionless Network Service", RFC 994, March 1986.
+
+   [7] Postel, J., "Internet Control Message Protocol (ICMP)", STD 5,
+       RFC 792, USC/Information Sciences Institute, September 1981.
+
+   [8] Braden, R., Editor, "Requirements for Internet Hosts -
+       Communication Layers", STD 3, RFC 1122, Internet Engineering Task
+       Force, October 1989.
+
+   [9] Hagens, R., "An Echo Function for ISO 8473", RFC 1139, IETF-OSI
+       Working Group, May 1993.
+
+  [10] Sklower, K., "Improving the Efficiency of the ISO Checksum
+       Calculation" ACM SIGCOMM CCR 18, no. 5 (October 1989):32-43.
+
+  [11] ISO/IEC 8348-1992. International Standards Organization--Data
+       Communications--OSI Network Layer Service and Addressing.
+
+
+
+
+
+Piscitello                                                     [Page 22]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+  [12] Callon, R., Gardner, E., and R. Hagens, "Guidelines for OSI NSAP
+       Allocation in the Internet", RFC 1237, NIST, Mitre, DEC, July
+       1991.
+
+  [13] Piscitello, D., "Assignment of System Identifiers for TUBA/CLNP
+       Hosts", RFC 1526, Bellcore, September 1993.
+
+  [14] ISO/IEC 9542:1988/PDAM 1. Information Processing Systems -- Data
+       Communications -- ES/IS Routeing Protocol for use with ISO CLNP
+       -- Amendment 1: Dynamic Discovery of OSI NSAP Addresses by End
+       Systems.
+
+  [15] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340
+       USC/Information Sciences Institute, July 1992.
+
+  [16] Kent, S., "Security Option for IP", RFC 1108, BBN Communications,
+       November 1991.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Piscitello                                                     [Page 23]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+Appendix A. Checksum Algorithms (from ISO/IEC 8473)
+
+       Symbols used in algorithms:
+
+        c0, c1          variables used in the algorithms
+        i               position of octet in header (first
+                        octet is i=1)
+        Bi              value of octet i in the header
+        n               position of first octet of checksum (n=8)
+        L               Length of header in octets
+        X               Value of octet one of the checksum parameter
+        Y               Value of octet two of the checksum parameter
+
+   Addition is performed in one of the two following modes:
+
+         * modulo 255 arithmetic;
+
+         * eight-bit one's complement arithmetic;
+
+   The algorithm for Generating the Checksum Parameter Value is as
+   follows:
+
+  A.  Construct the complete header with the value of the
+      checksum parameter field set to zero; i.e., c0 <- c1 <- 0;
+
+  B.  Process each octet of the header sequentially from i=1 to L
+      by:
+
+         * c0 <- c0 + Bi
+
+         * c1 <- c1 + c0
+
+  C.  Calculate X, Y as follows:
+
+         * X <- (L - 8)(c0 - c1) modulo 255
+
+         * Y <- (L - 7)(-C0) + c1
+
+  D.  If X = 0, then X <- 255
+
+  E.  If Y = 0, then Y <- 255
+
+  F.  place the values of X and Y in octets 8 and 9 of the
+      header, respectively
+
+   The algorithm for checking the value of the checksum parameter is as
+   follows:
+
+
+
+
+Piscitello                                                     [Page 24]
+
+RFC 1561               CLNP in TUBA Environments           December 1993
+
+
+  A.  If octets 8 and 9 of the header both contain zero, then the
+      checksum calculation has succeeded; else if either but not
+      both of these octets contains the value zero then the
+      checksum is incorrect; otherwise, initialize: c0 <- c1 <- 0
+
+  B.  Process each octet of the header sequentially from i = 1 to
+      L by:
+
+         * c0 <- c0 + Bi
+
+         * c1 <- c1 + c0
+
+  C.  When all the octets have been processed, if c0 = c1 = 0,
+      then the checksum calculation has succeeded, else it has
+      failed.
+
+   There is a separate algorithm to adjust the checksum parameter value
+   when a octet has been modified (such as the TTL). Suppose the value
+   in octet k is changed by Z = newvalue - oldvalue. If X and Y denote
+   the checksum values held in octets n and n+1 respectively, then
+   adjust X and Y as follows:
+
+   If X = 0 and Y = 0 then do nothing, else if X = 0 or Y = 0 then the
+   checksum is incorrect, else:
+
+   X <- (k - n - 1)Z + X   modulo 255
+
+   Y <- (n - k)Z + Y       modulo 255
+
+   If X = 0, then X <- 255; if Y = 0, then Y <- 255.
+
+   In the example, n = 89; if the octet altered is the TTL (octet 4),
+   then k = 4. For the case where the lifetime is decreased by one unit
+   (Z = -1), the assignment statements for the new values of X and Y in
+   the immediately preceeding algorithm simplify to:
+
+   X <- X + 5      Modulo 255
+
+   Y <- Y - 4      Modulo 255
+
+
+
+
+
+
+
+
+
+
+
+
+Piscitello                                                     [Page 25]
+
\ No newline at end of file