home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1500s / rfc1561.txt < prev    next >
Text File  |  1993-12-21  |  56KB  |  1,403 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      D. Piscitello
  8. Request for Comments: 1561                               Core Competence
  9. Category: Experimental                                     December 1993
  10.  
  11.  
  12.                   Use of ISO CLNP in TUBA Environments
  13.  
  14. Status of this Memo
  15.  
  16.    This memo defines an Experimental Protocol for the Internet
  17.    community.  This memo does not specify an Internet standard of any
  18.    kind.  Discussion and suggestions for improvement are requested.
  19.    Distribution of this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    This memo specifies a profile of the ISO/IEC 8473 Connectionless-mode
  24.    Network Layer Protocol (CLNP, [1]) for use in conjunction with RFC
  25.    1347, TCP/UDP over Bigger Addresses (TUBA, [2]).  It describes the
  26.    use of CLNP to provide the lower-level service expected by
  27.    Transmission Control Protocol (TCP, [3]) and User Datagram Protocol
  28.    (UDP, [4]).  CLNP provides essentially the same datagram service as
  29.    Internet Protocol (IP, [5]), but offers a means of conveying bigger
  30.    network addresses (with additional structure, to aid routing).
  31.  
  32.    While the protocols offer nearly the same services, IP and CLNP are
  33.    not identical. This document describes a means of preserving the
  34.    semantics of IP information that is absent from CLNP while preserving
  35.    consistency between the use of CLNP in Internet and OSI environments.
  36.    This maximizes the use of already-deployed CLNP implementations.
  37.  
  38. Acknowledgments
  39.  
  40.    Many thanks to Ross Callon (Wellfleet Communications), John Curran
  41.    (BBN), Cyndi Jung (3Com), Paul Brooks (UNSW), Brian Carpenter (CERN),
  42.    Keith Sklower (Cal Berkeley), Dino Farinacci and Dave Katz (Cisco
  43.    Systems), Rich Colella (NIST/CSL) and David Oran (DEC) for their
  44.    assistance in composing this text.
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Piscitello                                                      [Page 1]
  59.  
  60. RFC 1561               CLNP in TUBA Environments           December 1993
  61.  
  62.  
  63. Conventions
  64.  
  65.    The following language conventions are used in the items of
  66.    specification in this document:
  67.  
  68.          * MUST, SHALL, or MANDATORY -- the item is an absolute
  69.            requirement of the specification.
  70.  
  71.          * SHOULD or RECOMMENDED -- the item should generally be
  72.            followed for all but exceptional circumstances.
  73.  
  74.          * MAY or OPTIONAL -- the item is truly optional and may be
  75.            followed or ignored according to the needs of the
  76.            implementor.
  77.  
  78. 1.  Terminology
  79.  
  80.    To the extent possible, this document is written in the language of
  81.    the Internet. For example, packet is used rather than "protocol data
  82.    unit", and "fragment" is used rather than "segment".  There are some
  83.    terms that carry over from OSI; these are, for the most part, used so
  84.    that cross-reference between this document and RFC 994 [6] or ISO/IEC
  85.    8473 is not entirely painful.  OSI acronyms are for the most part
  86.    avoided.
  87.  
  88. 2.  Introduction
  89.  
  90.    The goal of this specification is to allow compatible and
  91.    interoperable implementations to encapsulate TCP and UDP packets in
  92.    CLNP data units. In a sense, it is more of a "hosts requirements"
  93.    document for the network layer of TUBA implementations than a
  94.    protocol specification. It is assumed that readers are familiar with
  95.    STD 5, RFC 791, STD 5, RFC 792 [7], STD 3, RFC 1122 [8], and, to a
  96.    lesser extent, RFC 994 and ISO/IEC 8473.  This document is compatible
  97.    with (although more restrictive than) ISO/IEC 8473; specifically, the
  98.    order, semantics, and processing of CLNP header fields is consistent
  99.    between this and ISO/IEC 8473.
  100.  
  101.    [Note: RFC 994 contains the Draft International Standard version of
  102.    ISO CLNP, in ASCII text. This is not the final version of the ISO/IEC
  103.    protocol specification; however, it should provide sufficient
  104.    background for the purpose of understanding the relationship of CLNP
  105.    to IP, and the means whereby IP information is to be encoded in CLNP
  106.    header fields. Postscript versions of ISO CLNP and associated routing
  107.    protocols are available via anonymous FTP from merit.edu, and may be
  108.    found in the directory /pub/ISO/IEC.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Piscitello                                                      [Page 2]
  115.  
  116. RFC 1561               CLNP in TUBA Environments           December 1993
  117.  
  118.  
  119. 3.  Overview of CLNP
  120.  
  121.    ISO CLNP is a datagram network protocol. It provides fundamentally
  122.    the same underlying service to a transport layer as IP. CLNP provides
  123.    essentially the same maximum datagram size, and for those
  124.    circumstances where datagrams may need to traverse a network whose
  125.    maximum packet size is smaller than the size of the datagram, CLNP
  126.    provides mechanisms for fragmentation (data unit identification,
  127.    fragment/total length and offset). Like IP, a checksum computed on
  128.    the CLNP header provides a verification that the information used in
  129.    processing the CLNP datagram has been transmitted correctly, and a
  130.    lifetime control mechanism ("Time to Live") imposes a limit on the
  131.    amount of time a datagram is allowed to remain in the internet
  132.    system. As is the case in IP, a set of options provides control
  133.    functions needed or useful in some situations but unnecessary for the
  134.    most common communications.
  135.  
  136.    Note that the encoding of options differs between the two protocols,
  137.    as do the means of higher level protocol identification. Note also
  138.    that CLNP and IP differ in the way header and fragment lengths are
  139.    represented, and that the granularity of lifetime control (time-to-
  140.    live) is finer in CLNP.
  141.  
  142.    Some of these differences are not considered "issues", as CLNP
  143.    provides flexibility in the way that certain options may be specified
  144.    and encoded (this will facilitate the use and encoding of certain IP
  145.    options without change in syntax); others, e.g., higher level
  146.    protocol identification and timestamp, must be accommodated in a
  147.    transparent manner in this profile for correct operation of TCP and
  148.    UDP, and continued interoperability with OSI implementations. Section
  149.    4 describes how header fields of CLNP must be populated to satisfy
  150.    the needs of TCP and UDP.
  151.  
  152.    Errors detected during the processing of a CLNP datagram MAY be
  153.    reported using CLNP Error Reports. Implementations of CLNP for TUBA
  154.    environments MUST be capable of processing Error Reports (this is
  155.    consistent with the 1992 edition (2)  of the ISO/IEC 8473 standard).
  156.    Control messages (e.g., echo request/reply and redirect) are
  157.    similarly handled in CLNP, i.e., identified as separate network layer
  158.    packet types.  The relationship between CLNP Error and Control
  159.    messages and Internet Control Message Protocol (ICMP, [7]), and
  160.    issues relating to the handling of these messages is described in
  161.    Section 5.
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Piscitello                                                      [Page 3]
  171.  
  172. RFC 1561               CLNP in TUBA Environments           December 1993
  173.  
  174.  
  175.    Table 1 provides a high-level comparison of CLNP to IP:
  176.  
  177.  Function              | ISO CLNP               | DOD IP
  178.  ----------------------|------------------------|-----------------------
  179.  Header Length         | indicated in octets    | in 32-bit words
  180.  Version Identifier    | 1 octet                | 4 bits
  181.  Lifetime (TTL)        | 500 msec units         | 1 sec units
  182.  Flags                 | Fragmentation allowed, | Don't Fragment,
  183.                        | More Fragments         | More Fragments,
  184.                        | Suppress Error Reports | <not defined>
  185.  Packet Type           | 5 bits                 | <not defined>
  186.  Fragment Length       | 16 bits, in octets     | 16 bits, in octets
  187.  Header Checksum       | 16-bit (Fletcher)      | 16-bit
  188.  Total Length          | 16 bits, in octets     | <not defined>
  189.  Addressing            | Variable length        | 32-bit fixed
  190.  Data Unit Identifier  | 16 bits                | 16 bits
  191.  Fragment offset       | 16 bits, in octets     | 13 bits, 8-octet units
  192.  Higher Layer Protocol | Selector in address    | Protocol
  193.  Options               | Security               | Security
  194.                        | Priority               | TOS Precedence bits
  195.                        | Complete Source Route  | Strict Source Route
  196.                        | Quality of Service     | Type of Service
  197.                        | Partial Source Route   | Loose Source Route
  198.                        | Record Route           | Record Route
  199.                        | Padding                | Padding
  200.                        | <defined herein>       | Timestamp
  201.  
  202.                  Table 1. Comparison of IP to CLNP
  203.  
  204.    The composition and processing of a TCP pseudo-header when CLNP is
  205.    used to provide the lower-level service expected by TCP and UDP is
  206.    described in Section 6.
  207.  
  208.    [Note: This experimental RFC does not discuss multicasting.
  209.    Presently, there are proposals for multicast extensions for CLNP in
  210.    ISO/IEC/JTC1/SC6, and a parallel effort within TUBA. A future
  211.    revision to this RFC will incorporate any extensions to CLNP that may
  212.    be introduced as a result of the adoption of one of these
  213.    alternatives.]
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Piscitello                                                      [Page 4]
  227.  
  228. RFC 1561               CLNP in TUBA Environments           December 1993
  229.  
  230.  
  231. 4.  Proposed Internet Header using CLNP
  232.  
  233.    A summary of the contents of the CLNP header, as it is proposed for
  234.    use in TUBA environments, is illustrated in Figure 4-1:
  235.  
  236.    0                   1                   2                   3
  237.    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
  238.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  239.   |        ........Data Link Header........       | NLP ID        |
  240.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  241.   |Header Length  |     Version   | Lifetime (TTL)|Flags|  Type   |
  242.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  243.   |        Fragment Length        |           Checksum            |
  244.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  245.   | Dest Addr Len |               Destination Address...          |
  246.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  247.   |               ... Destination Address...                      |
  248.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  249.   |               ... Destination Address...                      |
  250.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  251.   |               ... Destination Address...                      |
  252.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  253.   |               ... Destination Address...                      |
  254.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  255.   | PROTO field   | Src  Addr Len |  Source  Address...           |
  256.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  257.   |               ... Source Address...                           |
  258.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  259.   |               ... Source Address...                           |
  260.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  261.   |               ... Source Address...                           |
  262.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  263.   |               ... Source Address...                           |
  264.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  265.   |Source Address |   Reserved    |       Data Unit Identifier    |
  266.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  267.   |         Fragment Offset       |   Total Length of packet      |
  268.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  269.   |                   Options  (see Table 1)                      |
  270.   |                                                               |
  271.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  272.   |                               Data                            |
  273.   |                                                               |
  274.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  275.  
  276.          Note that each tick mark represents one bit position.
  277.  
  278.                      Figure 4-1. CLNP for TUBA
  279.  
  280.  
  281.  
  282. Piscitello                                                      [Page 5]
  283.  
  284. RFC 1561               CLNP in TUBA Environments           December 1993
  285.  
  286.  
  287.   Note 1: For illustrative purposes, Figure 4-1 shows Destination
  288.           and Source Addresses having a length of 19 octets,
  289.           including the PROTO/reserved field. In general, addresses
  290.           can be variable length, up to a maximum of 20 octets,
  291.           including the PROTO/reserved field.
  292.  
  293.   Note 2: Due to differences in link layer protocols, it is not
  294.           possible to ensure that the packet starts on an even
  295.           alignment. Note, however, that many link level protocols
  296.           over which CLNP is operated use a odd length link
  297.           (e.g., IEEE 802.2). (In Figure 4-1, the rest of the CLNP
  298.           packet is even-aligned.)
  299.  
  300.    The encoding of CLNP fields for use in TUBA environments is as
  301.    follows.
  302.  
  303. 4.1  Network Layer Protocol Identification (NLP ID)
  304.  
  305.    This one-octet field identifies this as the ISO/IEC 8473 protocol; it
  306.    MUST set to binary 1000 0001.
  307.  
  308. 4.2  Header Length Indication (Header Length)
  309.  
  310.    Header Length is the length of the CLNP header in octets, and thus
  311.    points to the beginning of the data. The value 255 is reserved. The
  312.    header length is the same for all fragments of the same (original)
  313.    CLNP packet.
  314.  
  315. 4.3  Version
  316.  
  317.    This one-octet field identifies the version of the protocol; it MUST
  318.    be set to a binary value 0000 0001.
  319.  
  320. 4.4  Lifetime (TTL)
  321.  
  322.    Like the TTL field of IP, this field indicates the maximum time the
  323.    datagram is allowed to remain in the internet system.  If this field
  324.    contains the value zero, then the datagram MUST be destroyed; a host,
  325.    however, MUST NOT send a datagram with a lifetime value of zero.
  326.    This field is modified in internet header processing.  The time is
  327.    measured in units of 500 milliseconds, but since every module that
  328.    processes a datagram MUST decrease the TTL by at least one even if it
  329.    process the datagram in less than 500 millisecond, the TTL must be
  330.    thought of only as an upper bound on the time a datagram may exist.
  331.    The intention is to cause undeliverable datagrams to be discarded,
  332.    and to bound the maximum CLNP datagram lifetime. [Like IP, the
  333.    colloquial usage of TTL in CLNP is as a coarse hop-count.]
  334.  
  335.  
  336.  
  337.  
  338. Piscitello                                                      [Page 6]
  339.  
  340. RFC 1561               CLNP in TUBA Environments           December 1993
  341.  
  342.  
  343.    Unless otherwise directed, a host SHOULD use a value of 255 as the
  344.    initial lifetime value.
  345.  
  346. 4.5  Flags
  347.  
  348.    Three flags are defined. These occupy bits 0, 1, and 2 of the
  349.    Flags/Type octet:
  350.  
  351.                           0   1   2
  352.                         +---+---+---+
  353.                         | F | M | E |
  354.                         | P | F | R |
  355.                         +---+---+---+
  356.  
  357.    The Fragmentation Permitted (FP) flag, when set to a value of one
  358.    (1), is semantically equivalent to the "may fragment" value of the
  359.    Don't Fragment field of IP; similarly, when set to zero (0), the
  360.    Fragmentation Permitted flag is semantically equivalent to the "Don't
  361.    Fragment" value of the Don't Fragment Flag of IP.
  362.  
  363.    [Note: If the Fragmentation Permitted field is set to the value 0,
  364.    then the Data Unit Identifier, Fragment Offset, and Total Length
  365.    fields are not present. This denotes a single fragment datagram. In
  366.    such datagrams, the Fragment Length field contains the total length
  367.    of the datagram.]
  368.  
  369.    The More Fragments flag of CLNP is semantically and syntactically the
  370.    same as the More Fragments flag of IP; a value of one (1) indicates
  371.    that more segments/fragments are forthcoming; a value of zero (0)
  372.    indicates that the last octet of the original packet is present in
  373.    this segment.
  374.  
  375.    The Error Report (ER) flag is used to suppress the generation of an
  376.    error message by a host/router that detects an error during the
  377.    processing of a CLNP datagram; a value of one (1) indicates that the
  378.    host that originated this datagram thinks error reports are useful,
  379.    and would dearly love to receive one if a host/router finds it
  380.    necessary to discard its datagram(s).
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Piscitello                                                      [Page 7]
  395.  
  396. RFC 1561               CLNP in TUBA Environments           December 1993
  397.  
  398.  
  399. 4.6  Type field
  400.  
  401.    The type field distinguishes data CLNP packets from Error Reports
  402.    from Echo packets. The following values of the type field apply:
  403.  
  404.      0   1   2   3   4   5   6   7
  405.    +---+---+---+---+---+---+---+---+
  406.    |   flags   | 1 | 1 | 1 | 0 | 0 |  => Encoding of Type = data packet
  407.    +---+---+---+---+---+---+---+---+
  408.    |   flags   | 0 | 0 | 0 | 0 | 1 |  => Encoding of Type = error report
  409.    +---+---+---+---+---+---+---+---+
  410.    |   flags   | 1 | 1 | 1 | 1 | 0 |  => Encoding of Type = echo request
  411.    +---+---+---+---+---+---+---+---+
  412.    |   flags   | 1 | 1 | 1 | 1 | 1 |  => Encoding of Type = echo reply
  413.    +---+---+---+---+---+---+---+---+
  414.  
  415.    Error Report packets are described in Section 5.
  416.  
  417.    Echo packets and their use are described in RFC 1139 [9].
  418.  
  419. 4.7  Fragment Length
  420.  
  421.    Like the Total Length of the IP header, the Fragment length field
  422.    contains the length in octets of the fragment (i.e., this datagram)
  423.    including both header and data.
  424.  
  425.    [Note: CLNP also may also have a Total Length field, that contains
  426.    the length of the original datagram; i.e., the sum of the length of
  427.    the CLNP header plus the length of the data submitted by the higher
  428.    level protocol, e.g., TCP or UDP. See Section 4.12.]
  429.  
  430. 4.8  Checksum
  431.  
  432.    A checksum is computed on the header only. It MUST be verified at
  433.    each host/router that processes the packet; if header fields are
  434.    changed during processing (e.g., the Lifetime), the checksum is
  435.    modified. If the checksum is not used, this field MUST be coded with
  436.    a value of zero (0). See Appendix A for algorithms used in the
  437.    computation and adjustment of the checksum. Readers are encouraged to
  438.    see [10] for a description of an efficient implementation of the
  439.    checksum algorithm.
  440.  
  441. 4.9  Addressing
  442.  
  443.    CLNP uses OSI network service access point addresses (NSAPAs); NSAPAs
  444.    serve the same identification and location functions as an IP
  445.    address, plus the protocol selector value encoded in the IPv4
  446.    datagram header, and  with additional hierarchy.  General purpose
  447.  
  448.  
  449.  
  450. Piscitello                                                      [Page 8]
  451.  
  452. RFC 1561               CLNP in TUBA Environments           December 1993
  453.  
  454.  
  455.    CLNP implementations MUST handle NSAP addresses of variable length up
  456.    to 20 octets, as defined in ISO/IEC 8348 [11]. TUBA implementations,
  457.    especially routers, MUST accommodate these as well. Thus, for
  458.    compatibility and interoperability with OSI use of CLNP, the initial
  459.    octet of the Destination Address is assumed to be an Authority and
  460.    Format Indicator, as defined in ISO/IEC 8348. NSAP addresses may be
  461.    between 8 and 20 octets long (inclusive).
  462.  
  463.    TUBA implementations MUST support both ANSI and GOSIP style
  464.    addresses; these are described in RFC 1237 [12], and illustrated in
  465.    Figure 4-2.  RFC 1237 describes the ANSI/GOSIP initial domain parts
  466.    as well as the format and composition of the domain specific part. It
  467.    is further recommended that TUBA implementations support the
  468.    assignment of system identifiers for TUBA/CLNP hosts defined in [13]
  469.    for the purposes of host address autoconfiguration as described in
  470.    [14]. Additional considerations specific to the interpretation and
  471.    encoding of the selector part are described in sections 4.9.2 and
  472.    4.9.4.
  473.  
  474.             +-------------+
  475.             | <-- IDP --> |
  476.             +----+--------+----------------------------------+
  477.             |AFI |  IDI   |           <-- DSP -->            |
  478.             +----+--------+----+---+-----+----+-----+---+----+
  479.             | 47 |  0005  |DFI |AA |Rsvd | RD |Area |ID |Sel |
  480.             +----+--------+----+---+-----+----+-----+---+----+
  481.      octets | 1  |   2    | 1  | 3 |  2  | 2  | 2   | 6 | 1  |
  482.             +----+--------+----+---+-----+----+-----+---+----+
  483.  
  484.                  Figure 4-2 (a): GOSIP Version 2 NSAP structure.
  485.  
  486.             +-------------+
  487.             |<-- IDP -->  |
  488.             +----+--------+----------------------------------+
  489.             |AFI |  IDI   |          <-- DSP -->             |
  490.             +----+--------+----+---+-----+----+-----+---+----+
  491.             | 39 |  840   |DFI |ORG|Rsvd | RD |Area |ID |Sel |
  492.             +----+--------+----+---+-----+----+-----+---+----+
  493.      octets | 1  |   2    | 1  | 3 |  2  | 2  |  2  | 6 | 1  |
  494.             +----+--------+----+---+-----+----+-----+---+----+
  495.  
  496.              Figure 4-2 (b): ANSI NSAP address format for DCC=840
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Piscitello                                                      [Page 9]
  507.  
  508. RFC 1561               CLNP in TUBA Environments           December 1993
  509.  
  510.  
  511.         Definitions:
  512.                      IDP   Initial Domain Part
  513.                      AFI   Authority and Format Identifier
  514.                      IDI   Initial Domain Identifier
  515.                      DSP   Domain Specific Part
  516.                      DFI   DSP Format Identifier
  517.                      AA    Administration Authority
  518.                      ORG   Organization Name (numeric form)
  519.                      Rsvd  Reserved
  520.                      RD    Routing Domain Identifier
  521.                      Area  Area Identifier
  522.                      ID    System Identifier
  523.                      Sel   NSAP Selector
  524.  
  525. 4.9.1  Destination Address Length Indicator
  526.  
  527.    This field indicates the length, in octets, of the Destination
  528.    Address.
  529.  
  530. 4.9.2  Destination Address
  531.  
  532.    This field contains an OSI NSAP address, as described in Section 4.9.
  533.    It MUST always contain the address of the final destination. (This is
  534.    true even for packets containing a source route option, see Section
  535.    4.13.4).
  536.  
  537.    The final octet of the destination address MUST always contain the
  538.    value of the PROTO field, as defined in IP.  The 8-bit PROTO field
  539.    indicates the next level protocol used in the data portion of the
  540.    CLNP datagram.  The values for various protocols are specified in
  541.    "Assigned Numbers" [15]. For the PROTO field, the value of zero (0)
  542.    is reserved.
  543.  
  544.    TUBA implementations that support TCP/UDP as well as OSI MUST use the
  545.    protocol value (1Dh, Internet decimal 29) reserved for ISO transport
  546.    protocol class 4.
  547.  
  548. 4.9.3  Source Address Length Indicator
  549.  
  550.    This field indicates the length, in octets, of the Source Address.
  551.  
  552. 4.9.4  Source Address
  553.  
  554.    This field contains an OSI NSAP address, as described in Section 4.9.
  555.  
  556.    The final octet of the source address is reserved. It MAY be set to
  557.    the protocol field value on transmission, and shall be ignored on
  558.    reception (the value of zero MUST not be used).
  559.  
  560.  
  561.  
  562. Piscitello                                                     [Page 10]
  563.  
  564. RFC 1561               CLNP in TUBA Environments           December 1993
  565.  
  566.  
  567. 4.10  Data Unit Identifier
  568.  
  569.    Like the Identification field of IP, this 16-bit field is used to
  570.    distinguish segments of the same (original) packet for the purposes
  571.    of reassembly. This field is present when the fragmentation permitted
  572.    flag is set to one.
  573.  
  574. 4.11  Fragment Offset
  575.  
  576.    Like the Fragment Offset of IP, this 16-bit is used to identify the
  577.    relative octet position of the data in this fragment with respect to
  578.    the start of the data submitted to CLNP; i.e., it indicates where in
  579.    the original datagram this fragment belongs.  The offset is measured
  580.    in octets; the value of this field shall always be a multiple of
  581.    eight (8). This field is present when the fragmentation permitted
  582.    flag is set to one.
  583.  
  584. 4.12  Total Length
  585.  
  586.    The total length of the CLNP packet in octets is determined by the
  587.    originator and placed in the Total Length field of the header. The
  588.    Total Length field specifies the entire length of the original
  589.    datagram, including both the header and data. This field MUST NOT be
  590.    changed in any fragment of the original packet for the duration of
  591.    the packet lifetime. This field is present when the fragmentation
  592.    permitted flag is set to one.
  593.  
  594. 4.13  Options
  595.  
  596.    All CLNP options are "triplets" of the form <parameter code>,
  597.    <parameter length>, and <parameter value>.  Both the parameter code
  598.    and length fields are always one octet long; the length parameter
  599.    value, in octets, is indicated in the parameter length field. The
  600.    following options are defined for CLNP for TUBA.
  601.  
  602. 4.13.1  Security
  603.  
  604.    The value of the parameter code field is binary 1100 0101. The length
  605.    field MUST be set to the length of a Basic (and Extended) Security IP
  606.    option(s) as identified in RFC 1108 [16], plus 1.  Octet 1 of the
  607.    security parameter value field -- the CLNP Security Format Code -- is
  608.    set to a binary value 0100 0000, indicating that the remaining octets
  609.    of the security field contain either the Basic or Basic and Extended
  610.    Security options as identified in RFC 1108. This encoding points to
  611.    the administration of the source address (e.g., ISOC) as the
  612.    administration of the security option; it is thus distinguished from
  613.    the globally unique format whose definition is reserved for OSI use.
  614.    Implementations wishing to use a security option MUST examine the
  615.  
  616.  
  617.  
  618. Piscitello                                                     [Page 11]
  619.  
  620. RFC 1561               CLNP in TUBA Environments           December 1993
  621.  
  622.  
  623.    PROTO field in the source address; if the value of PROTO indicates
  624.    the CLNP client is TCP or UDP, the security option described in RFC
  625.    1108 is used.
  626.  
  627.    [Note: If IP options change, TUBA implementations MUST follow the new
  628.    recommendations. This RFC, or revisions thereof, must document the
  629.    new recommendations to assure compatibility.]
  630.  
  631.    The formats of the Security option, encoded as a CLNP option, is as
  632.    follows. The CLNP option will be used to convey the Basic and
  633.    Extended Security options as sub-options; i.e., the exact encoding of
  634.    the Basic/Extended Security IP Option is carried in a single CLNP
  635.    Security Option, with the length of the CLNP Security option
  636.    reflecting the sum of the lengths of the Basic and Extended Security
  637.    IP Option.
  638.  
  639.    +--------+--------+--------+--------+--------+---//----+-
  640.    |11000100|XXXXXXXX|01000000|10000010|YYYYYYYY|         |      ...
  641.    +--------+--------+--------+--------+--------+---//----+----
  642.     CLNP       CLNP     CLNP     BASIC   BASIC    BASIC
  643.     OPTION    OPTION   FORMAT  SECURITY  OPTION   OPTION
  644.     TYPE      LENGTH    CODE    TYPE     LENGTH   VALUE
  645.     (197)                       (130)
  646.  
  647.                           ---+------------+------------+----//-------+
  648.                      ...     |  10000101  |  000LLLLL  |             |
  649.                         -----+------------+------------+----//-------+
  650.                                 EXTENDED     EXTENDED    EXTENDED OPTION
  651.                                 OPTION       OPTION          VALUE
  652.                                TYPE (133)    LENGTH
  653.  
  654.    The syntax, semantics and  processing of the Basic and Extended IP
  655.    Security Options are defined in RFC 1108.
  656.  
  657. 4.13.2  Type of Service
  658.  
  659.    [Note: Early drafts recommended the use of IP Type of Service as
  660.    specified in RFC 1349. There now appears to be a broad consensus that
  661.    this encoding is insufficient, and there is renewed interest in
  662.    exploring the utility of the "congestion experienced" flag available
  663.    in the CLNP QOS Maintenance option. This RFC thus recommends the use
  664.    of the QOS Maintenance option native to CLNP.]
  665.  
  666.    The Quality of Service Maintenance option allows the originator of a
  667.    CLNP datagram to convey information about the quality of service
  668.    requested by the originating upper layer process. Routers MAY use
  669.    this information as an aid in selecting a route when more than one
  670.    route satisfying other routing criteria is available and the
  671.  
  672.  
  673.  
  674. Piscitello                                                     [Page 12]
  675.  
  676. RFC 1561               CLNP in TUBA Environments           December 1993
  677.  
  678.  
  679.    available routes are know to differ with respect to the following
  680.    qualities of service: ability to preserve sequence, transit delay,
  681.    cost, residual error probability. Through this option, a router may
  682.    also indicate that it is experiencing congestion.
  683.  
  684.    The encoding of this option is as follows:
  685.  
  686.       +-----------+-----------+----------+
  687.       | 1100 0011 | 0000 0001 | 110ABCDE |
  688.       +-----------+-----------+----------+
  689.        CLNP QOS     OPTION      QOS FLAGS
  690.        TYPE (195)   LENGTH
  691.  
  692.    The value of the parameter code field MUST be set to a value of
  693.    binary 1100 0011 (the CLNP Quality of Service Option Code point).
  694.    The length field MUST be set to one (1).
  695.  
  696.    Bits 8-6 MUST be set as indicated in the figure. The flags "ABCDE"
  697.    are interpreted as follows:
  698.  
  699.          A=1  choose path that maintains sequence over
  700.               one that minimizes transit delay
  701.          A=0  choose path that minimizes transit delay over
  702.               one that maintains sequence
  703.          B=1  congestion experienced
  704.          B=0  no congestion to report
  705.          C=1  choose path that minimizes transit delay over
  706.               over low cost
  707.          C=0  choose low cost over path that
  708.               minimizes transit delay
  709.          D=1  choose pathe with low residual error probability over
  710.               one that minimizes transit delay
  711.          D=0  choose path that minimizes transit delay over
  712.               one with low residual error probability
  713.          E=1  choose path with low residual error probability over
  714.               low cost
  715.          E=0  choose path with low cost over one with low
  716.               residual error probability
  717.  
  718. 4.13.3  Padding
  719.  
  720.    The padding field is used to lengthen the packet header to a
  721.    convenient size. The parameter code field MUST be set to a value of
  722.    binary 1100 1100. The value of the  parameter length field is
  723.    variable. The parameter value MAY contain any value; the contents of
  724.    padding fields MUST be ignored by the receiver.
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Piscitello                                                     [Page 13]
  731.  
  732. RFC 1561               CLNP in TUBA Environments           December 1993
  733.  
  734.  
  735.       +----------+----------+-----------+
  736.       | 11001100 | LLLLLLLL | VVVV VVVV |
  737.       +----------+----------+-----------+
  738.  
  739. 4.13.4  Source Routing
  740.  
  741.    Like the strict source route option of IP, the Complete Source Route
  742.    option of CLNP is used to specify the exact and entire route an
  743.    internet datagram MUST take. Similarly, the Partial Source Route
  744.    option of CLNP provides the equivalent of the loose source route
  745.    option of IP; i.e., a means for the source of an internet datagram to
  746.    supply (some) routing information to be used by gateways in
  747.    forwarding the internet datagram towards its destination. The
  748.    identifiers encoded in this option are network entity titles, which
  749.    are semantically and syntactically the same as NSAPAs and which can
  750.    be used to unambiguously identify a network entity in an intermediate
  751.    system (router).
  752.  
  753.    The parameter code for Source Routing is binary 1100 1000. The length
  754.    of the source routing parameter value is variable.
  755.  
  756.    The first octet of the parameter value is a type code, indicating
  757.    Complete Source Routing (binary 0000 0001) or Partial Source Routing
  758.    (binary 0000 0000). The second octet identifies the offset of the
  759.    next network entity title to be processed in the list, relative to
  760.    the start of the parameter (i.e., a value of 3 is used to identify
  761.    the first address in the list). The offset value is modified by each
  762.    router using a complete source route or by each listed router using a
  763.    partial source route to point to the next NET.
  764.  
  765.    The third octet begins the list of network entity titles. Only the
  766.    NETs of intermediate systems are included in the list; the source and
  767.    destination addresses shall not be included.  The list consists of
  768.    variable length network entity title entries; the first octet of each
  769.    entry gives the length of the network entity title that comprises the
  770.    remainder of the entry.
  771.  
  772. 4.13.5  Record Route
  773.  
  774.    Like the IP record route option, the Record route option of CLNP is
  775.    used to trace the route a CLNP datagram takes.  A recorded route
  776.    consists of a list of network entity titles (see Source Routing). The
  777.    list is constructed as the CLNP datagram is forwarded along a path
  778.    towards its final destination. Only titles of intermediate systems
  779.    (routers) that processed the datagram are included in the recorded
  780.    route; the network entity title of the originator of the datagram
  781.    SHALL NOT be recorded in the list.
  782.  
  783.  
  784.  
  785.  
  786. Piscitello                                                     [Page 14]
  787.  
  788. RFC 1561               CLNP in TUBA Environments           December 1993
  789.  
  790.  
  791.    The parameter code for Record Route is binary 1100 1011. The length
  792.    of the record route parameter value is variable.
  793.  
  794.    The first octet of the parameter value is a type code, indicating
  795.    Complete Recording of Route (0000 0001) or Partial Recording of Route
  796.    (0000 0000). When complete recording of route is selected, reassembly
  797.    at intermediate systems MAY be performed only when all fragments of a
  798.    given datagram followed the same route; partial recording of route
  799.    eliminates or "loosens" this constraint.
  800.  
  801.    The second octet identifies the offset where the next network entity
  802.    title entry (see Source Routing) MAY be recorded (i.e., the end of
  803.    the current list), relative to the start of the parameter.  A value
  804.    of 3 is used to identify the initial recording position. The process
  805.    of recording a network entity title entry is as follows. A router
  806.    adds the length of its network entity title entry to the value of
  807.    record route offset and compares this new value to the record route
  808.    list length indicator; if the value does not exceed the length of the
  809.    list, entity title entry is recorded, and the offset value is
  810.    incremented by the value of the length of the network entity title
  811.    entry. Otherwise, the recording of route is terminated, and the
  812.    router MUST not record its network entity title in the option. If
  813.    recording of route has been terminated, this (second) octet has a
  814.    value 255.
  815.  
  816.    The third octet begins the list of network entity titles.
  817.  
  818. 4.13.6  Timestamp
  819.  
  820.    [Note: There is no timestamp option in edition 1 of ISO/IEC 8473, but
  821.    the option has been proposed and submitted to ISO/IEC JTC1/SC6.]
  822.  
  823.    The parameter code value 1110 1110 is used to identify the Timestamp
  824.    option; the syntax and semantics of Timestamp are identical to that
  825.    defined in IP.
  826.  
  827.    The Timestamp Option is defined in STD 5, RFC 791. The CLNP parameter
  828.    code 1110 1110 is used rather than the option type code 68 to
  829.    identify the Timestamp option, and  the parameter value conveys the
  830.    option length. Octet 1 of the Timestamp parameter value shall be
  831.    encoded as the pointer (octet 3 of IP Timestamp); octet 2 of the
  832.    parameter value shall be encoded as the overflow/format octet (octet
  833.    4 of IP Timestamp); the remaining octets shall be used to encode the
  834.    timestamp list. The size is fixed by the source, and cannot be
  835.    changed to accommodate additional timestamp information.
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Piscitello                                                     [Page 15]
  843.  
  844. RFC 1561               CLNP in TUBA Environments           December 1993
  845.  
  846.  
  847.         +--------+--------+--------+--------+
  848.         |11101110| length | pointer|oflw|flg|
  849.         +--------+--------+--------+--------+
  850.         |         network entity title      |
  851.         +--------+--------+--------+--------+
  852.         |             timestamp             |
  853.         +--------+--------+--------+--------+
  854.         |                 .                 |
  855.                           .
  856.  
  857. 5.  Error Reporting and Control Message Handling
  858.  
  859.    CLNP and IP  differ in the way in which errors are reported to hosts.
  860.    In IP environments, the Internet Control Message Protocol (ICMP, [7])
  861.    is used to return (error) messages to hosts that originate packets
  862.    that cannot be processed. ICMP messages are transmitted as user data
  863.    in IP datagrams. Unreachable destinations, incorrectly composed IP
  864.    datagram headers, IP datagram discards due to congestion, and
  865.    lifetime/reassembly time exceeded are reported; the complete internet
  866.    header that caused the error plus (at least) 8 octets of the segment
  867.    contained in that IP datagram are returned to the sender as part of
  868.    the ICMP error message. For certain errors, e.g., incorrectly
  869.    composed IP datagram headers, the specific octet which caused the
  870.    problem is identified.
  871.  
  872.    In CLNP environments, an unique message type, the Error Report type,
  873.    is used in the network layer protocol header to distinguish Error
  874.    Reports from CLNP datagrams. CLNP Error Reports are generated on
  875.    detection of the same types of errors as with ICMP.  Like ICMP error
  876.    messages, the complete CLNP header that caused the error is returned
  877.    to the sender in the data portion of the Error Report.
  878.    Implementations SHOULD return at least 8 octets of the datagram
  879.    contained in the CLNP datagram to the sender of the original CLNP
  880.    datagram. Here too, for certain errors, the specific octet which
  881.    caused the problem is identified.
  882.  
  883.    A summary of the contents of the CLNP Error Report, as it is proposed
  884.    for use in TUBA environments, is illustrated in Figure 5-1:
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Piscitello                                                     [Page 16]
  899.  
  900. RFC 1561               CLNP in TUBA Environments           December 1993
  901.  
  902.  
  903.     0                   1                   2                   3
  904.     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
  905.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  906.    |        ........Data Link Header........       | NLP ID        |
  907.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  908.    |Header Length  |     Version   | Lifetime (TTL)| 000 | Type=ER |
  909.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  910.    |  TOTAL Length of Error Report |           Checksum            |
  911.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  912.    | Dest Addr Len |               Destination Address...          |
  913.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  914.    |               ... Destination Address...                      |
  915.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  916.    |               ... Destination Address...                      |
  917.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  918.    |               ... Destination Address...                      |
  919.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  920.    |               ... Destination Address...                      |
  921.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  922.    | PROTO field   | Src  Addr Len |  Source  Address...           |
  923.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  924.    |               ... Source Address...                           |
  925.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  926.    |               ... Source Address...                           |
  927.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  928.    |               ... Source Address...                           |
  929.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  930.    |               ... Source Address...                           |
  931.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  932.    |       ... Source Address      | Reason for Discard (type/len) |
  933.    |                               |   1100 0001   | 0000 0010     |
  934.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  935.    |     Reason for Discard        |    Options...                 |
  936.    |   code        |   pointer     |                               |
  937.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  938.    |                           Options                             |
  939.    :                                                               :
  940.    |                                                               |
  941.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  942.    |                            Data                               |
  943.    :                                                               :
  944.    |                                                               |
  945.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  946.  
  947.              Note that each tick mark represents one bit position.
  948.  
  949.                       Figure 5-1. Error Report Format
  950.  
  951.  
  952.  
  953.  
  954. Piscitello                                                     [Page 17]
  955.  
  956. RFC 1561               CLNP in TUBA Environments           December 1993
  957.  
  958.  
  959. 5.1  Rules for processing an Error Report
  960.  
  961.    The following is a summary of the rules for processing an Error
  962.    Report:
  963.  
  964.          * An Error Report is not generated to report a problem
  965.            encountered while processing an Error Report.
  966.  
  967.          * Error Reports MAY NOT be fragmented (hence, the
  968.            fragmentation part is absent).
  969.  
  970.          * The Reason for Discard Code field is populated with one of
  971.            the values from Table 5-1.
  972.  
  973.          * The Pointer field is populated with number of the first
  974.            octet of the field that caused the Error Report to be
  975.            generated. If it is not possible to identify the offending
  976.            octet, this field MUST be zeroed.
  977.  
  978.          * If the Priority or Type of Service option is present in the
  979.            errored datagram, the Error Report MUST specify the same
  980.            option, using the value specified in the original datagram.
  981.  
  982.          * If the Security option is present in the errored datagram,
  983.            the Error Report MUST specify the same option, using the
  984.            value specified in the original datagram; if the Security
  985.            option is not supported by the intermediate system, no Error
  986.            Report is to be generated (i.e., "silently discard" the
  987.            received datagram).
  988.  
  989.          * If the Complete Source Route option is specified in the
  990.            errored datagram, the Error Report MUST compose a reverse of
  991.            that route, and return the datagram along the same path.
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Piscitello                                                     [Page 18]
  1011.  
  1012. RFC 1561               CLNP in TUBA Environments           December 1993
  1013.  
  1014.  
  1015. 5.2  Comparison of ICMP and CLNP Error Messages
  1016.  
  1017.    Table 5-1 provides a loose comparison of ICMP message types and codes
  1018.    to CLNP Error Type Codes (values in Internet decimal):
  1019.  
  1020.  CLNP Error Type  Codes            | ICMP Message           (Type, Code)
  1021.  ----------------------------------|------------------------------------
  1022.  Reason not specified          (0) | Parameter Problem           (12, 0)
  1023.  Protocol Procedure Error      (1) | Parameter Problem           (12, 0)
  1024.  Incorrect Checksum            (2) | Parameter Problem           (12, 0)
  1025.  PDU Discarded--Congestion     (3) | Source Quench                (4, 0)
  1026.  Header Syntax Error           (4) | Parameter problem           (12, 0)
  1027.  Need to Fragment could not    (5) | Frag needed, DF set          (3, 4)
  1028.  Incomplete PDU received       (6) | Parameter Problem           (12, 0)
  1029.  Duplicate Option              (7) | Parameter Problem           (12, 0)
  1030.  Destination Unreachable     (128) | Dest Unreachable,Net unknown (3, 0)
  1031.  Destination Unknown         (129) | Dest Unreachable,host unknown(3, 1)
  1032.  Source Routing Error        (144) | Source Route failed          (3, 5)
  1033.  Source Route Syntax Error   (145) | Source Route failed          (3, 5)
  1034.  Unknown Address in Src Route(146) | Source Route failed          (3, 5)
  1035.  Path not acceptable         (147) | Source Route failed          (3, 5)
  1036.  Lifetime expired            (160) | TTL exceeded                (11, 0)
  1037.  Reassembly Lifetime Expired (161) | Reassembly time exceeded    (11, 1)
  1038.  Unsupported Option          (176) | Parameter Problem           (12, 0)
  1039.  Unsupported Protocol Version(177) | Parameter problem           (12, 0)
  1040.  Unsupported Security Option (178) | Parameter problem           (12, 0)
  1041.  Unsupported Src Rte Option  (179) | Parameter problem           (12, 0)
  1042.  Unsupported Rcrd Rte        (180) | Parameter problem           (12, 0)
  1043.  Reassembly interference     (192) | Reassembly time exceeded    (11, 1)
  1044.  
  1045.     Table 5-1. Comparison of CLNP Error Reports to ICMP Error Messages
  1046.  
  1047.  Note 1: The current accepted practice for IP is that source quench
  1048.          should not be used; if it is used, implementations MUST
  1049.          not return a source quench packet for every relevant packet.
  1050.          TUBA/CLNP implementations are encouraged to adhere to these
  1051.          guidelines.
  1052.  
  1053.  Note 2: There are no corresponding CLNP Error Report Codes for the
  1054.          following ICMP error message types:
  1055.          - Protocol Unreachable  (3, 2)
  1056.          - Port Unreachable      (3, 3)
  1057.          [Note: Additional error code points available in the ER type
  1058.               code block can be used to identify these message types.]
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Piscitello                                                     [Page 19]
  1067.  
  1068. RFC 1561               CLNP in TUBA Environments           December 1993
  1069.  
  1070.  
  1071. 6.  Pseudo-Header Considerations
  1072.  
  1073.    A checksum is computed on UDP and TCP segments to verify the
  1074.    integrity of the UDP/TCP segment. To further verify that the UDP/TCP
  1075.    segment has arrived at its correct destination, a pseudo-header
  1076.    consisting of information used in the delivery of the UDP/TCP segment
  1077.    is composed and included in the checksum computation.
  1078.  
  1079.    To compute the checksum on a UDP or TCP segment prior to
  1080.    transmission, implementations MUST compose a pseudo-header to the
  1081.    UDP/TCP segment consisting of the following information that will be
  1082.    used when composing the CLNP datagram:
  1083.  
  1084.          * Destination Address Length Indicator
  1085.  
  1086.          * Destination Address (including PROTO field)
  1087.  
  1088.          * Source Address Length Indicator
  1089.  
  1090.          * Source Address (including Reserved field)
  1091.  
  1092.          * A two-octet encoding of the Protocol value
  1093.  
  1094.          * TCP/UDP segment length
  1095.  
  1096.    If the length of the {source address length field + source address +
  1097.    destination address field + destination address } is not an integral
  1098.    number of octets, a trailing 0x00 nibble is padded. If GOSIP
  1099.    compliant NSAP addresses are used, this never happens (this is known
  1100.    as the Farinacci uncertainty principle).  The last byte in the
  1101.    Destination Address has the value 0x06 for TCP and 0x11 for UDP, and
  1102.    the Protocol field is encoded 0x0006 for TCP and 0x0011 for UDP.  If
  1103.    needed, an octet of zero is added to the end of the UDP/TCP segment
  1104.    to pad the datagram to a length that is a multiple of 16 bits.
  1105.  
  1106.    [Note: the pseudoheader is encoded in this manner to expedite
  1107.    processing, as it allows implementations to grab a contiguous stream
  1108.    of octets beginning at the destination address length indicator and
  1109.    terminating at the final octet of the source address; the PROTOCOL
  1110.    field is present to have a consistent representation across IPv4 and
  1111.    CLNP/TUBA implementations.]
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Piscitello                                                     [Page 20]
  1123.  
  1124. RFC 1561               CLNP in TUBA Environments           December 1993
  1125.  
  1126.  
  1127.    Figure 6-1 illustrates the resulting pseudo-header when both source
  1128.    and destination addresses are maximum length.
  1129.  
  1130.     0                   1                   2                   3
  1131.     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
  1132.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1133.    | Dest Addr Len |               Destination Address...          |
  1134.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1135.    |               ... Destination Address...                      |
  1136.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1137.    |               ... Destination Address...                      |
  1138.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1139.    |               ... Destination Address...                      |
  1140.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1141.    |               ... Destination Address...                      |
  1142.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1143.    |    (PROTO)    | Src  Addr Len |  Source  Address...           |
  1144.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1145.    |               ... Source Address...                           |
  1146.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1147.    |               ... Source Address...                           |
  1148.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1149.    |               ... Source Address...                           |
  1150.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1151.    |               ... Source Address...                           |
  1152.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1153.    | ...           | (Reserved)    |    Protocol                   |
  1154.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1155.    |   UDP/TCP segment length      |
  1156.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1157.  
  1158.                            Figure 6-1. Pseudo-header
  1159.  
  1160. 7.  Security Considerations
  1161.  
  1162.    ISO CLNP is an unreliable network datagram protocol, and is subject
  1163.    to the same security considerations as Internet Protocol ([5], [8]);
  1164.    methods for conveying the same security handling information
  1165.    recommended for IP are described in Section 4.13.1, Security Option.
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Piscitello                                                     [Page 21]
  1179.  
  1180. RFC 1561               CLNP in TUBA Environments           December 1993
  1181.  
  1182.  
  1183. 8.  Author's Address
  1184.  
  1185.    David M. Piscitello
  1186.    Core Competence
  1187.    1620 Tuckerstown Road
  1188.    Dresher, PA 19025
  1189.  
  1190.    Phone: 215-830-0692
  1191.    EMail: wk04464@worldlink.com
  1192.  
  1193. 9.  References
  1194.  
  1195.    [1] ISO/IEC 8473-1992. International Standards Organization -- Data
  1196.        Communications -- Protocol for Providing the Connectionless
  1197.        Network Service, Edition 2.
  1198.  
  1199.    [2] Callon, R., "TCP/UDP over Bigger Addresses (TUBA)", RFC 1347,
  1200.        Internet Architecture Board, May 1992.
  1201.  
  1202.    [3] Postel, J., "Transmission Control Protocol (TCP)", STD 7, RFC
  1203.        793, USC/Information Sciences Institute, September 1981.
  1204.  
  1205.    [4] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768,
  1206.        USC/Information Sciences Institute, September 1981.
  1207.  
  1208.    [5] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791,
  1209.        USC/Information Sciences Institute, September 1981.
  1210.  
  1211.    [6] Chapin, L., "ISO DIS 8473, Protocol for Providing the
  1212.        Connectionless Network Service", RFC 994, March 1986.
  1213.  
  1214.    [7] Postel, J., "Internet Control Message Protocol (ICMP)", STD 5,
  1215.        RFC 792, USC/Information Sciences Institute, September 1981.
  1216.  
  1217.    [8] Braden, R., Editor, "Requirements for Internet Hosts -
  1218.        Communication Layers", STD 3, RFC 1122, Internet Engineering Task
  1219.        Force, October 1989.
  1220.  
  1221.    [9] Hagens, R., "An Echo Function for ISO 8473", RFC 1139, IETF-OSI
  1222.        Working Group, May 1993.
  1223.  
  1224.   [10] Sklower, K., "Improving the Efficiency of the ISO Checksum
  1225.        Calculation" ACM SIGCOMM CCR 18, no. 5 (October 1989):32-43.
  1226.  
  1227.   [11] ISO/IEC 8348-1992. International Standards Organization--Data
  1228.        Communications--OSI Network Layer Service and Addressing.
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Piscitello                                                     [Page 22]
  1235.  
  1236. RFC 1561               CLNP in TUBA Environments           December 1993
  1237.  
  1238.  
  1239.   [12] Callon, R., Gardner, E., and R. Hagens, "Guidelines for OSI NSAP
  1240.        Allocation in the Internet", RFC 1237, NIST, Mitre, DEC, July
  1241.        1991.
  1242.  
  1243.   [13] Piscitello, D., "Assignment of System Identifiers for TUBA/CLNP
  1244.        Hosts", RFC 1526, Bellcore, September 1993.
  1245.  
  1246.   [14] ISO/IEC 9542:1988/PDAM 1. Information Processing Systems -- Data
  1247.        Communications -- ES/IS Routeing Protocol for use with ISO CLNP
  1248.        -- Amendment 1: Dynamic Discovery of OSI NSAP Addresses by End
  1249.        Systems.
  1250.  
  1251.   [15] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340
  1252.        USC/Information Sciences Institute, July 1992.
  1253.  
  1254.   [16] Kent, S., "Security Option for IP", RFC 1108, BBN Communications,
  1255.        November 1991.
  1256.  
  1257.  
  1258.  
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Piscitello                                                     [Page 23]
  1291.  
  1292. RFC 1561               CLNP in TUBA Environments           December 1993
  1293.  
  1294.  
  1295. Appendix A. Checksum Algorithms (from ISO/IEC 8473)
  1296.  
  1297.        Symbols used in algorithms:
  1298.  
  1299.         c0, c1          variables used in the algorithms
  1300.         i               position of octet in header (first
  1301.                         octet is i=1)
  1302.         Bi              value of octet i in the header
  1303.         n               position of first octet of checksum (n=8)
  1304.         L               Length of header in octets
  1305.         X               Value of octet one of the checksum parameter
  1306.         Y               Value of octet two of the checksum parameter
  1307.  
  1308.    Addition is performed in one of the two following modes:
  1309.  
  1310.          * modulo 255 arithmetic;
  1311.  
  1312.          * eight-bit one's complement arithmetic;
  1313.  
  1314.    The algorithm for Generating the Checksum Parameter Value is as
  1315.    follows:
  1316.  
  1317.   A.  Construct the complete header with the value of the
  1318.       checksum parameter field set to zero; i.e., c0 <- c1 <- 0;
  1319.  
  1320.   B.  Process each octet of the header sequentially from i=1 to L
  1321.       by:
  1322.  
  1323.          * c0 <- c0 + Bi
  1324.  
  1325.          * c1 <- c1 + c0
  1326.  
  1327.   C.  Calculate X, Y as follows:
  1328.  
  1329.          * X <- (L - 8)(c0 - c1) modulo 255
  1330.  
  1331.          * Y <- (L - 7)(-C0) + c1
  1332.  
  1333.   D.  If X = 0, then X <- 255
  1334.  
  1335.   E.  If Y = 0, then Y <- 255
  1336.  
  1337.   F.  place the values of X and Y in octets 8 and 9 of the
  1338.       header, respectively
  1339.  
  1340.    The algorithm for checking the value of the checksum parameter is as
  1341.    follows:
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Piscitello                                                     [Page 24]
  1347.  
  1348. RFC 1561               CLNP in TUBA Environments           December 1993
  1349.  
  1350.  
  1351.   A.  If octets 8 and 9 of the header both contain zero, then the
  1352.       checksum calculation has succeeded; else if either but not
  1353.       both of these octets contains the value zero then the
  1354.       checksum is incorrect; otherwise, initialize: c0 <- c1 <- 0
  1355.  
  1356.   B.  Process each octet of the header sequentially from i = 1 to
  1357.       L by:
  1358.  
  1359.          * c0 <- c0 + Bi
  1360.  
  1361.          * c1 <- c1 + c0
  1362.  
  1363.   C.  When all the octets have been processed, if c0 = c1 = 0,
  1364.       then the checksum calculation has succeeded, else it has
  1365.       failed.
  1366.  
  1367.    There is a separate algorithm to adjust the checksum parameter value
  1368.    when a octet has been modified (such as the TTL). Suppose the value
  1369.    in octet k is changed by Z = newvalue - oldvalue. If X and Y denote
  1370.    the checksum values held in octets n and n+1 respectively, then
  1371.    adjust X and Y as follows:
  1372.  
  1373.    If X = 0 and Y = 0 then do nothing, else if X = 0 or Y = 0 then the
  1374.    checksum is incorrect, else:
  1375.  
  1376.    X <- (k - n - 1)Z + X   modulo 255
  1377.  
  1378.    Y <- (n - k)Z + Y       modulo 255
  1379.  
  1380.    If X = 0, then X <- 255; if Y = 0, then Y <- 255.
  1381.  
  1382.    In the example, n = 89; if the octet altered is the TTL (octet 4),
  1383.    then k = 4. For the case where the lifetime is decreased by one unit
  1384.    (Z = -1), the assignment statements for the new values of X and Y in
  1385.    the immediately preceeding algorithm simplify to:
  1386.  
  1387.    X <- X + 5      Modulo 255
  1388.  
  1389.    Y <- Y - 4      Modulo 255
  1390.  
  1391.  
  1392.  
  1393.  
  1394.  
  1395.  
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402. Piscitello                                                     [Page 25]
  1403.