| RFC: 760 IEN: 128 |
January 1980
January 1980
January 1980
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | |Voice| ... | |
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | RTP | ... | |
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol |
+-------------------------------+
|
+---------------------------+
| Local Network Protocol |
+---------------------------+
|
Protocol Relationships
Figure 1.
Internet protocol interfaces on one side to the higher level
host-to-host protocols and on the other side to the local network
protocol.
January 1980
Application Application
Program Program
\ /
Internet Module Internet Module Internet Module
\ / \ /
LNI-1 LNI-1 LNI-2 LNI-2
\ / \ /
Local Network 1 Local Network 2
Transmission Path
Figure 2
January 1980
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Datagram Header
Figure 3.
Note that each tick mark represents one bit position.
Version: 4 bits
The Version field indicates the format of the internet header. This
document describes version 4.
IHL: 4 bits
Internet Header Length is the length of the internet header in 32
bit words, and thus points to the beginning of the data. Note that
the minimum value for a correct header is 5.
[Page 11]
January 1980
Bit 3: Stream or Datagram.
Bits 4-5: Reliability.
Bit 6: Speed over Reliability.
Bits 7: Speed.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | |
| PRECEDENCE | STRM|RELIABILITY| S/R |SPEED|
| | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
PRECEDENCE STRM RELIABILITY S/R SPEED
111-Flash Override 1-STREAM 11-highest 1-speed 1-high
110-Flash 0-DTGRM 10-higher 0-rlblt 0-low
11X-Immediate 01-lower
01X-Priority 00-lowest
00X-Routine
The type of service is used to specify the treatment of the datagram
during its transmission through the internet system. In the
discussion (section 3.2) below, a chart shows the relationship of
the internet type of service to the actual service provided on the
ARPANET, the SATNET, and the PRNET.
Total Length: 16 bits
Total Length is the length of the datagram, measured in octets,
including internet header and data. This field allows the length of
a datagram to be up to 65,535 octets. Such long datagrams are
impractical for most hosts and networks. All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
0 1 2
+---+---+---+
| | D | M |
| 0 | F | F |
+---+---+---+
Fragment Offset: 13 bits
This field indicates where in the datagram this fragment belongs.
The fragment offset is measured in units of 8 octets (64 bits). The
first fragment has offset zero.
Time to Live: 8 bits
This field indicates the maximum time the datagram is allowed to
remain the internet system. If this field contains the value zero,
then the datagram should be destroyed. This field is modified in
internet header processing. The time is measured in units of
seconds. The intention is to cause undeliverable datagrams to be
discarded.
[Page 13]
January 1980
1 bit reserved, must be zero
2 bits option class,
5 bits option number.
The option classes are:
0 = control
1 = internet error
2 = experimental debugging and measurement
3 = reserved for future use
[Page 15]
January 1980
----- ------ ------ -----------
0 0 - End of Option list. This option occupies only
1 octet; it has no length octet.
0 1 - No Operation. This option occupies only 1
octet; it has no length octet.
0 2 4 Security. Used to carry Security, and user
group (TCC) information compatible with DOD
requirements.
0 3 var. Source Routing. Used to route the internet
datagram based on information supplied by the
source.
0 7 var. Return Route. Used to record the route an
internet datagram takes.
0 8 4 Stream ID. Used to carry the stream
identifier.
1 1 var. General Error Report. Used to report errors
in internet datagram processing.
2 4 6 Internet Timestamp.
2 5 6 Satellite Timestamp.
Specific Option Definitions
End of Option List
+--------+
|00000000|
+--------+
Type=0
This option indicates the end of the option list. This might
not coincide with the end of the internet header according to
the internet header length. This is used at the end of all
options, not the end of each option, and need only be used if
the end of the options would not otherwise coincide with the end
of the internet header.
May be copied, introduced, or deleted on fragmentation.
+--------+
|00000001|
+--------+
Type=1
This option may be used between options, for example, to align
the beginning of a subsequent option on a 32 bit boundary.
May be copied, introduced, or deleted on fragmentation.
Security
This option provides a way for DOD hosts to send security and
TCC (closed user groups) parameters through networks whose
transport leader does not contain fields for this information.
The format for this option is as follows:
+--------+--------+---------+--------+
|00000010|00000100|000000SS | TCC |
+--------+--------+---------+--------+
Type=2 Length=4
Security: 2 bits
Specifies one of 4 levels of security
11-top secret
10-secret
01-confidential
00-unclassified
Transmission Control Code: 8 bits
Provides a means to compartmentalize traffic and define
controlled communities of interest among subscribers.
Note that this option does not require processing by the
internet module but does require that this information be passed
to higher level protocol modules. The security and TCC
information might be used to supply class level and compartment
information for transmitting datagrams into or through
AUTODIN II.
Must be copied on fragmentation.
[Page 17]
January 1980
+--------+--------+--------+---------//--------+
|00000011| length | source route |
+--------+--------+--------+---------//--------+
Type=3
The source route option provides a means for the source of an
internet datagram to supply routing information to be used by
the gateways in forwarding the datagram to the destination.
The option begins with the option type code. The second octet
is the option length which includes the option type code and the
length octet, as well as length-2 octets of source route data.
A source route is composed of a series of internet addresses.
Each internet address is 32 bits or 4 octets. The length
defaults to two, which indicates the source route is empty and
the remaining routing is to be based on the destination address
field.
If the address in destination address field has been reached and
this option's length is not two, the next address in the source
route replaces the address in the destination address field, and
is deleted from the source route and this option's length is
reduced by four. (The Internet Header Length Field must be
changed also.)
Must be copied on fragmentation.
Return Route
+--------+--------+--------+---------//--------+
|00000111| length | return route |
+--------+--------+--------+---------//--------+
Type=7
The return route option provides a means to record the route of
an internet datagram.
The option begins with the option type code. The second octet
is the option length which includes the option type code and the
length octet, as well as length-2 octets of return route data.
A return route is composed of a series of internet addresses.
The length defaults to two, which indicates the return route is
empty.
+--------+--------+---------+--------+
|00001000|00000010| Stream ID |
+--------+--------+---------+--------+
Type=8 Length=4
This option provides a way for the 16-bit SATNET stream
identifier to be carried through networks that do not support
the stream concept.
Must be copied on fragmentation.
General Error Report
+--------+--------+--------+--------+--------+----//----+
|00100001| length |err code| id | |
+--------+--------+--------+--------+--------+----//----+
Type=33
The general error report is used to report an error detected in
processing an internet datagram to the source internet module of
that datagram. The "err code" indicates the type of error
detected, and the "id" is copied from the identification field
of the datagram in error, additional octets of error information
may be present depending on the err code.
If an internet datagram containing the general error report
option is found to be in error or must be discarded, no error
report is sent.
ERR CODE:
0 - Undetermined Error, used when no information is available
about the type of error or the error does not fit any defined
class. Following the id should be as much of the datagram
(starting with the internet header) as fits in the option
space.
1 - Datagram Discarded, used when specific information is
[Page 19]
January 1980
Reason Description
------ -----------
0 No Reason
1 No One Wants It - No higher level protocol or
application program at destination wants this
datagram.
2 Fragmentation Needed & DF - Cannot deliver with out
fragmenting and has don't fragment bit set.
3 Reassembly Problem - Destination could not
reassemble due to missing fragments when time to
live expired.
4 Gateway Congestion - Gateway discarded datagram due
to congestion.
The error report is placed in a datagram with the following
values in the internet header fields:
Version: Same as the datagram in error.
IHL: As computed.
Type of Service: Zero.
Total Length: As computed.
Identification: A new identification is selected.
Flags: Zero.
Fragment Offset: Zero.
Time to Live: Sixty.
Protocol: Same as the datagram in error.
Header Checksum: As computed.
Source Address: Address of the error reporting module.
Destination Address: Source address of the datagram in error.
Options: The General Error Report Option.
Padding: As needed.
Not copied on fragmentation, goes with first fragment.
Internet Timestamp
+--------+--------+--------+--------+--------+--------+
|01000100|00000100| time in milliseconds |
+--------+--------+--------+--------+--------+--------+
Type=68 Length=6
The data of the timestamp is a 32 bit time measured in
milliseconds.
+--------+--------+--------+--------+--------+--------+
|01000101|00000100| time in milliseconds |
+--------+--------+--------+--------+--------+--------+
Type=69 Length=6
The data of the timestamp is a 32 bit time measured in
milliseconds.
Not copied on fragmentation, goes with first fragment
Padding: variable
The internet header padding is used to ensure that the internet
header ends on a 32 bit boundary. The padding is zero.
January 1980
has all zero fragmentation information (MF = 0, fragment offset =
0). If an internet datagram is fragmented, its data portion must be
broken on 8 octet boundaries.
This format allows 2**13 = 8192 fragments of 8 octets each for a
total of 65,536 octets. Note that this is consistent with the the
datagram total length field.
When fragmentation occurs, some options are copied, but others
remain with the first fragment only.
Every internet module must be able to forward a datagram of 68
octets without further fragmentation. This is because an internet
header may be up to 60 octets, and the minimum fragment is 8 octets.
Every internet destination must be able to receive a datagram of 576
octets either in one piece or in fragments to be reassembled.
FO - Fragment Offset
IHL - Internet Header Length
MF - More Fragments flag
TL - Total Length
OFO - Old Fragment Offset
OIHL - Old Internet Header Length
OMF - Old More Fragments flag
OTL - Old Total Length
NFB - Number of Fragment Blocks
MTU - Maximum Transmission Unit
[Page 23]
January 1980
value equals buffer size (e.g., 10Kb/s X 15s = 150Kb).
Notation:
FO - Fragment Offset
IHL - Internet Header Length
MF - More Fragments flag
TTL - Time To Live
NFB - Number of Fragment Blocks
TL - Total Length
TDL - Total Data Length
BUFID - Buffer Identifier
RCVBT - Fragment Received Bit Table
TLB - Timer Lower Bound
[Page 25]
January 1980
(2) IF FO = 0 AND MF = 0
(3) THEN IF buffer with BUFID is allocated
(4) THEN flush all reassembly for this BUFID;
(5) Submit datagram to next step; DONE.
(6) ELSE IF no buffer with BUFID is allocated
(7) THEN allocate reassembly resources
with BUFID;
TIMER <- TLB; TDL <- 0;
(8) put data from fragment into data buffer with
BUFID from octet FO*8 to
octet (TL-(IHL*4))+FO*8;
(9) set RCVBT bits from FO
to FO+((TL-(IHL*4)+7)/8);
(10) IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
(11) IF FO = 0 THEN put header in header buffer
(12) IF TDL # 0
(13) AND all RCVBT bits from 0
to (TDL+7)/8 are set
(14) THEN TL <- TDL+(IHL*4)
(15) Submit datagram to next step;
(16) free all reassembly resources
for this BUFID; DONE.
(17) TIMER <- MAX(TIMER,TTL);
(18) give up until next fragment or timer expires;
(19) timer expires: flush all reassembly with this BUFID; DONE.
In the case that two or more fragments contain the same data
either identically or through a partial overlap, this procedure
will use the more recently arrived copy in the data buffer and
datagram delivered.
Identification
The choice of the Identifier for a datagram is based on the need to
provide a way to uniquely identify the fragments of a particular
datagram. The protocol module assembling fragments judges fragments
to belong to the same datagram if they have the same source,
destination, protocol, and Identifier. Thus, the sender must choose
the Identifier to be unique for this source, destination pair and
protocol for the time the datagram (or any fragment of it) could be
alive in the internet.
It seems then that a sending protocol module needs to keep a table
of Identifiers, one entry for each destination it has communicated
with in the last maximum packet lifetime for the internet.
January 1980
Precedence: 5
Stream: 0
Reliability: 1
S/R: 1
Speed: 1
The mapping of these parameters to those available for the ARPANET
would be to set the ARPANET priority bit on since the Internet
priority is in the upper half of its range, to select uncontrolled
messages since the speed and reliability requirements are equal and
speed is preferred.
The following chart presents the recommended mappings from the
internet protocol type of service into the service parameters
actually available on the ARPANET, the PRNET, and the SATNET:
+------------+----------+----------+----------+----------+
|Application | INTERNET | ARPANET | PRNET | SATNET |
+------------+----------+----------+----------+----------+
|TELNET |S/D:stream| T: 3 | R: ptp | T: block |
| on | R:normal| S: S | A: no | D: min |
| TCP |S/R:speed | | | H: inf |
| | S:fast | | | R: no |
+------------+----------+----------+----------+----------+
|FTP |S/D:stream| T: 0 | R: ptp | T: block |
| on | R:normal| S: M | A: no | D: normal|
| TCP |S/R:rlblt | | | H: inf |
| | S:normal| | | R: no |
+------------+----------+----------+----------+----------+
|interactive |S/D:strm* | T: 3 | R: ptp | T: stream|
|narrow band | R:least | S: S | A: no | D: min |
| speech | P:speed | | | H: short |
| | S:asap | | | R: no |
+------------+----------+----------+----------+----------+
|datagram |S/D:dtgrm | T: 3 or 0| R:station| T: block |
| | R:normal| S: S or M| A: no | D: min |
| |S/R:speed | | | H: short |
| | S:fast | | | R: no |
+------------+----------+----------+----------+----------+
key: S/D=strm/dtgrm T=type R=route T=type
R=reliability S=size A=ack D=delay
S/R=speed/rlblt H=holding time
S=speed R=reliability
*=requires stream set up
January 1980
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 123 | Protocol = 1 | header checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+
Example Internet Datagram
Figure 4.
Note that each tick mark represents one bit position.
This is a internet datagram in version 4 of internet protocol; the
internet header consists of five 32 bit words, and the total length
of the datagram is 21 octets. This datagram is a complete datagram
(not a fragment).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 472 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 123 | Protocol = 6 | header checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Datagram
Figure 5.
[Page 31]
January 1980
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 276 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=1| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 119 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Fragment
Figure 6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 216 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 119 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Fragment
Figure 7.
[Page 33]
January 1980
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 8 |Type of Service| Total Length = 576 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 123 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = x | Opt. Len.= 3 | option value | Opt. Code = x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Len. = 4 | option value | Opt. Code = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = y | Opt. Len. = 3 | option value | Opt. Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Datagram
Figure 8.
dest = destination address
TOS = type of service
TTL = time to live
BufPTR = buffer pointer
len = length of buffer
Id = Identifier
DF = Don't Fragment
options = option data
result = response
OK = datagram sent ok
Error = error in arguments or local network error
RECV (BufPTR => result, source, dest, prot, TOS, len)
where:
BufPTR = buffer pointer
result = response
OK = datagram received ok
Error = error in arguments
source = source address
dest = destination address
prot = protocol
TOS = type of service
len = length of buffer
When the user sends a datagram, it executes the SEND call supplying
all the arguments. The internet protocol module, on receiving this
call, checks the arguments and prepares and sends the message. If the
arguments are good and the datagram is accepted by the local network,
the call returns successfully. If either the arguments are bad, or
the datagram is not accepted by the local network, the call returns
unsuccessfully. On unsuccessful returns, a reasonable report should
be made as to the cause of the problem, but the details of such
reports are up to individual implementations.
When a datagram arrives at the internet protocol module from the local
network, either there is a pending RECV call from the user addressed
or there is not. In the first case, the pending call is satisfied by
passing the information from the datagram to the user. In the second
case, the user addressed is notified of a pending datagram. If the
[Page 35]
January 1980
January 1980
January 1980
January 1980