Internet DRAFT - draft-piscitello-clnp

draft-piscitello-clnp



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 10:50:58 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 09 Dec 1992 04:34:00 GMT
ETag: "3dde4f-a3dd-2b257738"
Accept-Ranges: bytes
Content-Length: 41949
Connection: close
Content-Type: text/plain


IETF								1
September 3, 1992        CLNP for TUBA             Internet Draft
Expires in 6 months


              Use of ISO CLNP in TUBA Environments


              David M. Piscitello
                    Bellcore
                  dave@sabre.bellcore.com


                       Status of this Memo

This document is an Internet Draft.  Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts).

Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time.  It is not appropriate to use
Internet Drafts as reference material or to cite them other than
as a "working draft" or "work in progress."

Please check the Internet Draft abstract listing contained in the
IETF Shadow Directories (cd internet-drafts) to learn the current
status of this or any other Internet Draft.


This Internet-Draft specifies a profile of the ISO 8473
Connectionless-mode Network Layer Protocol (CLNP, [1]) for use in
conjunction with RFC 1347, TCP/UDP over Bigger Addresses (TUBA,
[2]).  This draft document will be submitted to the RFC editor as
a protocol specification. Distribution of this memo is unlimited.
Please send comments to dave@sabre.bellcore.com.


                            Abstract

This document 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










IETF								2
Internet Draft            CLNP for TUBA         September 3, 1992


Many thanks to Ross Callon of Digital Equipment and Dave Katz of
Cisco Systems for their lightning-quick replies to my frequent
requests for sanity-checks. Thanks also to the members of the
tuba mailing list, who commented on an earlier draft of this
paper.


                           Conventions

The following language conventions are used in the items of
specification in this document:

   o+ Must, Shall, or Mandatory -- the item is an absolute
     requirement of the specification.

   o+ Should or Recommended -- the item should generally be
     followed for all but exceptional circumstances.

   o+ 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 RFC994 or ISO 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. It is assumed that readers are familiar with
RFC 791 and, to a lesser extent, RFC 994 and ISO 8473.  This
document is compatible with (although more restrictive than) ISO
8473; specifically, the order, semantics, and processing of CLNP
header fields is consistent between this and ISO 8473.  However,
it is intended that this document be able to stand on its own
without reference to ISO 8473, at least with respect to
implementing CLNP to provide the lower-level service expected by
TCP and UDP.

[Editor's Note: RFC 994 contains the Draft International Standard
version of ISO CLNP [6]; while this is not the final version of
the ISO protocol specification, 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









IETF								3
September 3, 1992        CLNP for TUBA             Internet Draft


in CLNP header fields. More importantly, it's available on-
line:-)]


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. Errors detected during the processing of a CLNP
datagram may be reported using CLNP Error Reports.

Table 1 provides a high-level comparison of CLNP to IP:



Function                | ISO CLNP              | DOD IP
------------------------|-----------------------|-----------------
Version Identifier      | 1 octet               | 4 bits
Header Length           | indicated in octets   | in 32-bit words
Total Length            | 16 bits, in octets    | 16 bits, in octets
Data Unit Identifier    | 16 bits               | 16 bits
Flags                   | Fragmentation allowed,| Don't Fragment,
                        | More Fragments        | More Fragments,
                        | Suppress Error Reports| <not defined>
Fragment offset         | 16 bits, in octets    | 13 bits, 8-octet units
Lifetime (Time to live) | 500 msec units        | 1 sec units
Higher Layer Protocol   | Selector in address   | PROTOcol (assigned #)
Header Checksum         | 16-bit (Fletcher)     | 16-bit
Addressing              | Variable length       | 32-bit fixed
Options                 | Security              | Security
                        | Priority              | Precedence bits in TOS
                        | Complete Source Route | Strict Source Route
                        | Quality of Service    | Type of Service
                        | Partial Source Route  | Loose Source Route
                        | Record Route          | Record Route
                        | Padding               | Padding
                        | <not defined>         | Timestamp



                Table 1. Comparison of IP to CLNP









IETF								4
Internet Draft            CLNP for TUBA         September 3, 1992


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.

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. An unique message
type, the Error Report, is used in CLNP. Table 2 provides a loose
comparison of ICMP messages to CLNP Error Reports.



CLNP Error Report               | ICMP Message
--------------------------------|---------------------------------
Reason not specified            | <>
Protocol Procedure Error        | <>
Incorrect Checksum              | <>
PDU Discarded--Congestion       | Source Quench (Note 1)
Header Syntax Error             | Parameter problem
Needed to Fragment, could not   | Needed to Fragment, Don't Fragment set
Incomplete PDU received         | <>
Duplicate Option                | <>
Destination Unreachable         | Destination Unreachable
Destination Unknown             | Remote Net/Host Unknown (2)
Source Routing Error            | Source Route failed
Unknown Address in Source Route | Source Route failed(?)
Path not acceptable             | <>
Lifetime expired in transit     | Time to live exceeded
Reassembly Lifetime Expired     | Fragment reassembly time exceeded
Unsupported Option              | <>
Unsupported Protocol Version    | Parameter problem
Unsupported Security Option     | Parameter problem
Unsupported Source Route Option | Parameter problem
Unsupported Record Route option | Parameter problem
Reassembly interference         | <>
Echo Request/Reply              | CLNP Ping, see RFC1139 (3)
Redirect                        | RD packet of ES/IS protocol (4)


   Table 2. Comparison of CLNP Error Reports to ICMP Messages










IETF								5
September 3, 1992        CLNP for TUBA             Internet Draft


[Editor's Note: <> means I could find not comparable value; it is
an open issue whether these error messages may be used in TUBA
environments.  An analysis of the error reporting of CLNP and
ICMP continues.]


Note 1: The current use of the source quench is only
        when packets are discarded, and thus the current use
        meaning is the same; if a future RFC describes a more
        robust treatment of the source quench, the applicability
        of this CLNP Error Report Type should be reconsidered.

Note 2: Remote Net Unknown and Remote Host Unknown are defined as
        sub-options of the ICMP Destination Unreachable message in
        RFC1122, Host Requirements.

Note 3: The long-term option defined in RFC1139 shall be used. This is
        consistent with the current ISO proposal/addendum [cf].

Note 4: The Redirect packet of the ISO End System to Intermediate
        System Routing Exchange Protocol (ISO 9542) is used.



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 1:


































IETF								6
Internet Draft            CLNP for TUBA         September 3, 1992



    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...                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                                                               :
   |                    Options  (see Table 1)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Note that each tick mark represents one bit position.


                     Figure 1. CLNP for TUBA

The encoding of CLNP fields for use in TUBA environments is as
follows.














IETF								7
September 3, 1992        CLNP for TUBA             Internet Draft


4.1  Network Layer Protocol Identification (NLP ID)

This one-octet field identifies this as the ISO 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.  Note that the minimum
value for a correct header -- when CLNP is used to convey TCP or
UDP -- is 57.  This assumes both the source and destination
addresses are precisely 20 octets long, including the "protocol"
and "protocol/reserved" fields, respectively. (This also assumes
that no options are present). 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
is 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.  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.]

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









IETF								8
Internet Draft            CLNP for TUBA         September 3, 1992


"Don't Fragment" value of the Don't Fragment Flag of IP.

If the Fragmentation Permitted field has the value O, then the
Data Unit Identifier, Fragment Offset, and Total Length fields
are not present.

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).

4.6  Type field

The type field distinguishes data CLNP packets from Error
Reports; a value of binary 11100 in bits 3-7 of the Flags/Type
octet indicates that this is a data packet; a value of binary
00001 (go figure...) indicates that this is an Error Report.


  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
+---+---+---+---+---+---+---+---+



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 has 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).

4.8  Checksum

A checksum on the header only, 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.









IETF								9
September 3, 1992        CLNP for TUBA             Internet Draft


4.9  Destination Address Length Indicator ()

This field indicates the length, in octets, of the Destination
Address. It must be set to the value 20.

4.10  Destination Address

The format of the address encoded in this field is described in a
companion addressing document, see [8]; Appendix B briefly
identifies the formats under consideration at this time.

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 8348 [7]. A
destination address must be 20 octets long; the 20th octet 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" [9]. For the PROTO
field, the value of zero (0) is reserved.

4.11  Source Address Length Indicator ()

This field indicates the length, in octets, of the Source
Address.  It must be set to the value 20.

4.12  Source Address

The format of the address encoded in this field is described in a
companion addressing document, see [8]. Appendix B briefly
identifies the formats under consideration at this time.

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 8348 [7]. A
destination address must be 20 octets long; the 20th octet must
always be reserved. It may be set to the protocol field value on
transmission, and shall be ignored on reception. For the 20th
octet, the value of zero is reserved.

4.13  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.

4.14  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.










IETF							       10
Internet Draft            CLNP for TUBA         September 3, 1992


4.15  Options

All CLNP options are of the form <parameter code>, <parameter
lenth>, 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.15.1  _S_e_c_u_r_i_t_y

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 RFC1108 [10], 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 [10]. 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 must examine the PROTO field in the
source address; if the value of PROTO indicates the CLNP client
is TCP or UDP, the security option described in RFC1108 is used.

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













IETF							       11
September 3, 1992        CLNP for TUBA             Internet Draft


The syntax, semantics and  processing of the Basic and Extended
IP Security Options are defined in RFC1108.


4.15.2  _T_y_p_e__o_f__S_e_r_v_i_c_e

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 the length of the type of service
field as identified in RFC1349, Type of Service in the Internet
Protocol Suite [11], plus 1 (i.e., the value is 2). Octet 1 of
the type of service parameter field is set to a binary value 0100
0000, indicating that the remaining octet of the Type Of Service
field is to be encoded as described in RFC1349.  This encoding
points to the administration of the source address (e.g., ISOC)
as the administration of the CLNP QOS option; it is thus
distinguished from the globally unique QOS format whose
definition is reserved for OSI use.  Implementations must examine
the PROTO field in the source address; if the value of PROTO
indicates the CLNP client is TCP or UDP, the TOS described in
RFC1349 is used.


+-----------+----------+----------+----------+
| 1100 0011 | 00000010 | 01000000 | PPPTTTT0 |
+-----------+----------+----------+----------+
 CLNP QOS     OPTION    QOS FORMAT  IP TOS
 TYPE (195)   LENGTH       CODE      OCTET


The Type of Service octet consists of three fields:


   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|   PRECEDENCE    |          TOS          | MBZ |
+-----+-----+-----+-----+-----+-----+-----+-----+

The first field, labeled "PRECEDENCE" above, is intended to
denote the importance or priority of the datagram. The second
field, labeled "TOS" above, denotes how the network should make
tradeoffs between throughput, delay, reliability, and cost. The
last field must be zero ("MBZ").

The processing of the type of service option is defined in
RFC1349. The rules for applying TOS in Error and Report messages
should correspond to those applied to the corresponding ICMP
messages; i.e., error messages must always be sent with the
default TOS; request messages may have any correct TOS value, and
replies must be sent with the same value in the TOS field as was
used in the corresponding request message.











IETF							       12
Internet Draft            CLNP for TUBA         September 3, 1992


[Editor's Note: It has been suggested that the IP precedence map
directly into a CLNP option, Priority. The  feature will be
provided irrespective of whether precedence is encoded in the TOS
or Priority option.]

4.15.3  _P_a_d_d_i_n_g

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.


+----------+----------+-----------+
| 11001100 | LLLLLLLL | VVVV VVVV |
+----------+----------+-----------+

4.15.4  _S_o_u_r_c_e__R_o_u_t_i_n_g

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 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 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). A complete description of the
encoding of the parameter values of this option is to be
provided.

4.15.5  _R_e_c_o_r_d__R_o_u_t_e

Like the IP record route option, the Record route option of CLNP
is used to trace the route a CLNP datagram takes.

The parameter code for Record Route is binary 1100 1011. The
length of the record route parameter value is variable. A
complete description of the parameter value of this option is to
be provided.

4.15.6  _T_i_m_e_s_t_a_m_p

[Editor's Note: There is no timestamp option in CLNP. We propose
to define the option and submit it to ISO; temporarily, we will
be most presumptuous and "borrow" a code point from the many that
are reserved.]










IETF							       13
September 3, 1992        CLNP for TUBA             Internet Draft


This paper proposes that the parameter code value 1110 1110 be
used to identify the Timestamp option, and that the syntax and
semantics of Timestamp be identical to that defined in IP.

The Timestamp Option is defined in RFC 791. It is proposed that
the parameter code 1110 1110 be used rather than the option type
code 68 to identify the Timestamp option, and that the parameter
value convey 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.


        +--------+--------+--------+--------+
        |11101110| length | pointer|oflw|flg|
        +--------+--------+--------+--------+
        |         internet address          |
        +--------+--------+--------+--------+
        |             timestamp             |
        +--------+--------+--------+--------+
        |                 .                 |
                          .





































IETF							       14
Internet Draft            CLNP for TUBA         September 3, 1992


5.  REFERENCES

[1]     ISO 8473--International Standards Organization--Data
        Communications-- Protocol for Providing the
        Connectionless-mode Network Service

[2]     Callon, R., TCP/UDP over Bigger Addresses (TUBA), Request for
        Comments 1347, Network Information Center, SRI
        International, Menlo Park, CA, May 1992.

[3]     Postel, J., Transmission ControlProtocol. Request for
        Comments 793, Network Information Center, SRI
        International, Menlo Park, CA, 1981 September.

[4]     RFC768, User Datagram Protocol. Request for Comments 768,
        Network Information Center, SRI International, Menlo Park,
        CA <date>

[5]     Postel, J., Internet Protocol. Request for Comments 791,
        Network Information Center, SRI International, Menlo Park,
        CA, 1981 September.

[6]     RFC994, ISO CLNP, Draft International Standard version.

[7]     ISO8348--International Standards Organization--Data
        Communications--OSI Network Layer Addressing

[8]     RFCiiii, Addressing for the new Internet

[9]     RFC1340, Reynolds, J., and J. Postel, Assigned Numbers.

[10]    RFC1108, Kent, S., Security Option for IP.

[11]    RFC1349, Almquist, P., Type of Service in the Internet
        Protocol Suite.

[12]    ISO 6523 -- International Code Designators

























IETF							       15
September 3, 1992        CLNP for TUBA             Internet Draft


Appendix A. Checksum Algorithms (from ISO 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:

   o+ modulo 255 arithmetic;

   o+ 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:

         o+ c0 <- c0 + Bi

         o+ c1 <- c1 + c0

  C.  Calculate X, Y as follows:

         o+ X <- (L - 8)(c0 - c1) modulo 255

         o+ 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:

  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









IETF							       16
Internet Draft            CLNP for TUBA         September 3, 1992


  B.  Process each octet of the header sequentially from i = 1 to
      L by:

         o+ c0 <- c0 + Bi

         o+ 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




























IETF							       17
September 3, 1992        CLNP for TUBA             Internet Draft


Appendix B. Address formats

At least two alternatives for an ISOC network address format have
been posted to the TUBA list. In both cases, the actual "bits for
routing" are virtually identical; the encoding of the highest
level administration -- the Internet Society -- differs because
in case 1, the Internet Society applies directly to ISO/CCITT for
an authority code-point at the highest branch of the addressing
tree. This would be recorded in the OSI Network Layer Addressing
Standard, ISO 8438 [ ]. Thus, for case 1, the encoding of a
network address is as follows:


CASE 1: ISOC obtains an AFI.
        In this case, the format of the address, left-to-right is:

 <AFI>        1 byte   Identifies "ISOC"
 <addr type>  1 byte   Identifies type of address format. Currently
                       assigned value is "service provider". Future
                       values might specify "geographic", "flat", etc..
                       (note that "flat" would provide a globally unique
                       address which would not be routed by public service
                       providers).

if addr type specifies "service provider", rest of address looks like:

 <top-level>  2 bytes  Identifies country, or continent (for international
                       networks), or "inter-continental network".
                       NOTE: Top-level is included in case, in the future,
                       we have more than 10,000 service providers, and need
                       to route between them hierarchically.
 <PSP>        2 bytes  Specifies public service provider
                       (regional or backbone)
                       NOTE: So long as there are no more than 10,000
                       public service providers worldwide, routing between
                       them would be on a "flat" basis, using the first 6
                       bytes of the address as if it were a flat field.
 <reserved>   3 bytes  Reserved for future use, as will be specified by
                       the IETF. This is intended for future hierarchical
                       assignment of customer addresses by PSP's (i.e.,
                       will be used when there are more than 10,000
                       customers attached to a single PSP).
 <RD>         2 bytes  Identifies the RD which is a customer of a PSP
 <area>       2 bytes  Identifies the area within the routing domain
 <ID>         6 bytes  Identifies the host. This is globally unique.
 <protocol>   1 byte   Identifies higher level protocol running over CLNP.
                       (Uses values from current "assigned numbers" RFC)

 total:      20 bytes













IETF							       18
Internet Draft            CLNP for TUBA         September 3, 1992


In case 2, the ISOC applies for an International Code Designator
(ICD) from ISO/CCITT; the ICD's are assigned out of the AFI
code-point 47, which says that the two octets that immediately
follow the AFI identify an international organization, in this
case "ISOC". The ICD code point would be recorded in ISO 6523
[12], International Code Designators.


CASE 2: ISOC obtains an ICD.
        In this case, the format of the address, left-to-right is:

 <AFI>        1 byte   Identifies "ISO6523-ICD"
 <ICD>        2 bytes  ICD = "ISOC"
 <addr type>  1 byte   Identifies type of address format. Currently
                       assigned value is "service provider". Future
                       values might specify "geographic", "flat", etc..
                       (note that "flat" would provide a globally unique
                       address which would not be routed by public service
                       providers).

if addr type specifies "service provider", rest of address looks like:

 <top-level>  2 bytes  Identifies country, or continent (for international
                       networks), or "inter-continental network".
                       NOTE: Top-level is included in case, in the future,
                       we have more than 10,000 service providers, and need
                       to route between them hierarchically.
 <PSP>        2 bytes  Specifies public service provider
                       (regional or backbone)
                       NOTE: So long as there are no more than 10,000
                       public service providers worldwide, routing between
                       them would be on a "flat" basis, using the first 6
                       bytes of the address as if it were a flat field.
 <reserved>   1 byte   Reserved for future use, as will be specified by
                       the IETF. This is intended for future hierarchical
                       assignment of customer addresses by PSP's (i.e.,
                       will be used when there are more than 10,000
                       customers attached to a single PSP).
 <RD>         2 bytes  Identifies the RD which is a customer of a PSP
 <area>       2 bytes  Identifies the area within the routing domain
 <ID>         6 bytes  Identifies the host. This is globally unique.
 <protocol>   1 byte   Identifies higher level protocol running over CLNP.
                       (Uses values from current "assigned numbers" RFC)

 total:      20 bytes



Note that in both cases 1 and 2, the total length has been fixed
at a maximum length of 20 octets; note also that the use of CLNP
described in this Internet-draft requires only that the last
(20th) octet of the network addresses be reserved to encode the
PROTO value from IPv4, and that network addresses eventually used









IETF							       19
September 3, 1992        CLNP for TUBA             Internet Draft


be fixed to a maximum length of 20 octets to take advantage of a
fixed sized header for more efficient processing (when options
are not used).

The use of TUBA should not prevent use of any NSAPA format.  Some
backbone and regional networks currently use addresses that do
not conform to the requirement of a fixed length 20 octet
address; thus, the following has been proposed to the tuba
mailing list:

   o+ For the long term, addresses must be 20 octets long.

   o+ The last 7 octets of the address shall consist of a globally
     meaningful identifier of 6 octets plus a selector field of
     one octet, which shall use "protocol" values from Assigned
     Numbers.

   o+ The high order 13 octets of the address may make use of any
     valid NSAP address.

   o+ In the near term, (until (mm/dd/yy)), other address lengths
     are also permitted, but in all cases the low order seven
     octets must consists of an ID plus selector. Networks which
     are currently using shorter NSAPAs are required to be
     updated by this date. Hosts and routers may be optimized for
     20 octet network addresses, but until mm/dd/yy they are
     required to support shorter addresses.

   o+ When a system is using CLNP for other protocol suites (in
     addition to the Internet suite), it is permissible to do
     either of the following:

       1.  The addresses used for the other suites may be taken
           from the same space as addresses used with TUBA. In
           this case, the selector, representing the last octet
           of the NSAPA, must use the values from Assigned
           Numbers (note that there is a value for OSI TP Class 4
           defined in Assigned Numbers).

       2.  The address used for the other suites may be taken
           from a different space from addresses used with TUBA.
           In this case, the addresses used for other purposes
           (e.g., for OSI over CLNP) would be different from the
           addresses used for running TUBA over CLNP. In this
           case, a host which is running both Internet
           applications and OSI applications over CLNP would need
           at least two different NSAPAs assigned to it.















IETF							       20
Internet Draft            CLNP for TUBA         September 3, 1992


Appendix C. Issues

  1.  Is it useful to mandate in the CLNP for TUBA profile that
      both the QoS and Priority options be present in every
      packet? We can define a fixed correspondence of IP ToS to
      CLNP QoS and IP Precedence to CLNP Priority. It has been
      suggested that this would make the host changes easier and
      provide another dimension in which the functionality of the
      two packet encodings would be isomorphic.

  2.  Shall we use the AFI = ISOC or ISO 6523-ICD = ISOC form of
      network addressing?

  3.  We must obtain a codepoint for the Timestamp Option from
      ISO.

  4.  Is it useful to pursue the use of the congestion
      experienced bit?