CLNP for TUBA
Dave Piscitello <dave@sabre.bellcore.com> Mon, 10 August 1992 21:37 UTC
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa20047; 10 Aug 92 17:37 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa20041; 10 Aug 92 17:37 EDT
Received: from p.lanl.gov by NRI.Reston.VA.US id aa12559; 10 Aug 92 17:38 EDT
Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA08127; Mon, 10 Aug 92 15:30:20 -0600
Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA06215; Mon, 10 Aug 92 15:25:48 MDT
Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA06211; Mon, 10 Aug 92 15:25:45 MDT
Received: from sabre.bellcore.com by p.lanl.gov (5.65/1.14) id AA07951; Mon, 10 Aug 92 15:25:43 -0600
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA00193; Mon, 10 Aug 92 16:21:33 EDT
Return-Path: <dave@sabre.bellcore.com>
Received: by japan (4.1/4.7) id AA03310; Mon, 10 Aug 92 16:03:19 EDT
Date: Mon, 10 Aug 1992 16:03:19 -0400
From: Dave Piscitello <dave@sabre.bellcore.com>
X-Station-Sent-From: japan.bellcore.com
Message-Id: <9208102003.AA03310@japan>
To: tuba@lanl.gov
Subject: CLNP for TUBA
Hi,
I've taken a cut at "profiling" ISO 8473 as it might be used in
TUBA environments. I've tried to respond to many of the criticisms
of CLNP posted on big-internets (there are so many I am sure I
missed at least one:-) I specifically did not address the issue
of the checksum; as Ross has indicated in earlier postings, the
issue of whether the checksum is too slow or more powerful is one
I don't have sufficient "field experience" information to evaluate;
opinions as to how this should be handled are solicited.
I don't think I've done anything to CLNP that would make it
incompatible with existing implementations; let me know if I have:-)
---------
IETF Page 1
August 10, 1992 CLNP for TUBA Internet Draft
Use of ISO CLNP in TUBA Environments
Dave Piscitello
Bellcore
dave@sabre.bellcore.com
Status of this Memo
This document specifies a profile of the ISO 8473
Connectionless-mode Network Layer Protocol data units (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, in order to aid routing).
While the protocols offer nearly the same services, IP and CLNP
are not identical. This document describes a means of preserving
the semantics of IP information that is absent from CLNP while
preserving consistency between the use of CLNP in Internet and
OSI environments. This maximizes the use of already-deployed CLNP
implementations.
Acknowledgments
Many thanks to Ross Callon of Digital Equipment and Dave Katz of
Cisco Systems for their lightning-quick replies to my frequent
requests for sanity-checks.
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.
IETF Page 2
Internet Draft CLNP for TUBA August 10, 1992
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"; "fragment" is used rather than "segment"
and byte is used rather than "octet". 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 ISO 8473. This document is compatible with (although
more restrictive than) ISO 8473. However, it is intended that
this document be able to stand on its own without reference to
ISO 8473.
[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
in CLNP header fields.]
3. Overview of CLNP
ISO CLNP is a datagram network protocol. It provides
fundamentally the same underlying service to a transport layer as
IP. Table 1 provides a high-level comparison of CLNP to IP:
IETF Page 3
August 10, 1992 CLNP for TUBA Internet Draft
Function | ISO CLNP | DOD IP
------------------------|-----------------------|-----------------
Version Identifier | 1 byte | 4 bits
Header Length | indicated in bytes | in 32-bit words
Total Length | 16 bits, in bytes | 16 bits, in bytes
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 bytes | 13 bits, 8-byte 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 | <not defined>
| 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
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 non-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, 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 also 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 environments.
Table 2 provides a loose comparison of ICMP messages to CLNP
Error Reports.
IETF Page 4
Internet Draft CLNP for TUBA August 10, 1992
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 | Destination Unreachable
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 | <>
[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. Some of these error messages may correspond to ICMP
messages described in RFC1122, Host Requirements. A complete
analysis of the error reporting of CLNP and ICMP is required.]
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.
Table 2. Comparison of CLNP Error Reports to ICMP Messages
4. CLNP Header Format--Internet Style
A summary of the contents of the CLNP header, as it is proposed
for use in TUBA environments follows:
IETF Page 5
August 10, 1992 CLNP for TUBA Internet Draft
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... | 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
Due to differences in link layer protocols, it is not possible to
ensure that the packet starts on an even alignment. Note,
however, that many links happen to use a odd length link (eg,
802.2). Thus, the Network Layer Protocol Identifier, although
nominally the first byte of the CLNP header, may be considered as
part of the link layer in order to re-obtain even alignment. As
profiled, the rest of the CLNP packet is even aligned.
IETF Page 6
Internet Draft CLNP for TUBA August 10, 1992
The encoding of CLNP fields for use in TUBA environments is as
follows.
4.1 Network Layer Protocol Identification (NLP ID)
This one-byte 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 bytes, and thus
points to the beginning of the data. Note that the minimum value
for a correct header is 55 (assumes source and destination
addresses are always precisely 19 bytes long, including the
"protocol" and "protocol/reserved" fields, respectively. Also
assumes no options are present). The value 255 is reserved. The
header length is the same for all fragments of an originated CLNP
packet.
4.3 Version
This one-byte 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 a
second, 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.
4.5 Flags
Three flags are defined. These occupy bits 0, 1, and 2 of the
Flags/Type byte:
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 Page 7
August 10, 1992 CLNP for TUBA Internet Draft
"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 byte 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
byte 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 | 0 | => 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 bytes 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 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 Annex A.
IETF Page 8
Internet Draft CLNP for TUBA August 10, 1992
4.9 Destination Address Length Indicator ()
This field indicates the length, in bytes, of the Destination
Address. It must be set to the value 19.
4.10 Destination Address
The format of the address encoded in this field is described in a
companion addressing document, see [8].
For compatibility and interoperability with OSI use of CLNP, the
initial byte of the Destination Address is assumed to be an
Authority and Format Indicator, as defined in ISO 8348 [7]. A
destination address must be 19 bytes long; the 19th byte 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].
4.11 Source Address Length Indicator ()
This field indicates the length, in bytes, of the Source Address.
It must be set to the value 19.
4.12 Source Address
The format of the address encoded in this field is described in a
companion addressing document, see [8].
For compatibility and interoperability with OSI use of CLNP, the
initial byte of the Destination Address is assumed to be an
Authority and Format Indicator, as defined in ISO 8348 [7]. A
destination address must be 19 bytes long; the 19th byte must
always be reserved. It may be set to the protocol field value on
transmission, and shall be ignored on reception.
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 byte 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 Page 9
August 10, 1992 CLNP for TUBA Internet Draft
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 byte long; the length parameter
value, in bytes, is indicated in the parameter length field. The
following options are defined for CLNP for TUBA.
[Editor's note: whether the CLNP Priority option may be useful in
TUBA envirnoments is for further study. I have omitted this
option in this draft.]
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 or extended
security option as identified in RFC1108 [10], plus 1. Byte 1 of
the security parameter value field is set to a binary value 0100
0000, indicating that the remaining bytes of the security field
contain either the basic or extended security options as
identified in RFC 1108 [10]. The processing of the security
option is defined in RFC1108.
This encoding points to the administration of the source address
(e.g., ISOC) as the administration of the security option; it is
distinguished from the globally unique format whose definition is
reserved for OSI.
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 length field must be set to the length of
the type of service field as identified in RFCxxxx [11], plus 1.
Byte 1 of the type of service parameter field is set to a binary
value 0100 0000, indicating that the remaining bytes of the type
of service field are to be encoded as described in RFCxxxx. The
processing of the type of service option is defined in RFCxxxx.
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.
4.15.4 _S_o_u_r_c_e__R_o_u_t_i_n_g
The Complete and Partial Source Route options of CLNP replace the
strict and loose source route options of IP, respectively.
The parameter code for Source Routing is binary 1100 1000. The
length of the source routing parameter value is variable. The
first byte of the parameter value is a type code, indicating
IETF Page 10
Internet Draft CLNP for TUBA August 10, 1992
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 deferred until
the format and semantics of addressing is better defined.
4.15.5 _R_e_c_o_r_d__R_o_u_t_e
The Record route option of CLNP replaces the record route option.
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
deferred until format and semantics of addressing is better
defined.
4.15.6 _T_i_m_e_s_t_a_m_p
There is no timestamp option in CLNP. Two choices exist: define
the option and submit it to ISO, or steal a parameter code point
from the many that are reserved. 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 issue of whether the code
point is usurped or codified in ISO 8473 is left open.
The Timestamp 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. Byte 1 of the Timestamp parameter value
shall be encoded as the pointer (byte 3 of IP Timestamp); byte 2
of the parameter value shall be encoded as the overflow/format
byte (byte 4 of IP Timestamp); the remaining bytes shall be used
to encode the timestamp list. The size is fixed by the source,
and cannot be changed to accommodate additional timestamp
information.
5. REFERENCES
IETF Page 11
August 10, 1992 CLNP for TUBA Internet Draft
[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] RFCjjjj, Assigned Numbers
[10] RFC1108, Kent, S., Security Option for IP.
[11] RFCxxxx, Almquist, P., Type of Service
Appendix A. Checksum Algorithms (from ISO 8473)
Symbols used in algorithms:
c0, c1 variables used in the algorithms
i position of byte in header (first
byte is i=1)
Bi value of byte i in the header
n position of first byte of checksum (n=8)
L Length of header in bytes
X Value of byte one of the checksum parameter
Y Value of byte two of the checksum parameter
IETF Page 12
Internet Draft CLNP for TUBA August 10, 1992
Addition is performed in on of the two following modes:
o+ module 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 byte 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 bytes 8 and 9 of the header,
respectively
The algorithm for checking the value of the checksum parameter is
as follows:
A. If bytes 8 and 9 of the header both contain zero, then the
checksum calculation has succeeded; else if either but not
both of these bytes contains the value zero then the
checksum is incorrect; otherwise, initialize: c0 <- c1 <- 0
B. Process each octet of the header sequentially from i = 1 to
L by:
o+ c0 <- c0 + Bi
o+ c1 <- c1 + c0
C. When all the bytes 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 byte has been modified (such as the TTL). Suppose
IETF Page 13
August 10, 1992 CLNP for TUBA Internet Draft
the value in byte k is changed by Z = newvalue - oldvalue. If X
and Y denote the checksum values held in bytes 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 byte altered is the TTL (byte 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
- CLNP for TUBA Dave Piscitello
- CLNP for TUBA Dave Piscitello
- Re: CLNP for TUBA Beast (Donald E. Eastlake, 3rd)
- CLNP for TUBA minshall