IEN: 97
FLEXIBLE DATAGRAM PROTOCOL
Version 1
April 1979
prepared for
Defense Communication Agency
WWMCCS ADP Directorate
Command and Control Technical Center
11440 Isaac Newton Square
Reston, Va. 22090
by
MITRE Corporation
1820 Dolley Madision Blvd.
McLean Va. 22102
April 1979 Flexible Datagram Protocol
TABLE OF CONTENTS
Page
PREFACE . . . . . . . . . . . . . . . . . . . . . . . ii
INTRODUCTION . . . . . . . . . . . . . . . . . . . . 1
Motivation . . . . . . . . . . . . . . . . . . . 1 Scope . . . . . . . . . . . . . . . . . . . . . . 1 Interfaces . . . . . . . . . . . . . . . . . . . 2
OVERVIEW . . . . . . . . . . . . . . . . . . . . . . 2
Framework . . . . . . . . . . . . . . . . . . . 2
Protocol Mechanisms . . . . . . . . . . . . . . . 2
Network Addressing . . . . . . . . . . . . . 2
Host Addressing . . . . . . . . . . . . . . . 2
Reliability . . . . . . . . . . . . . . . . . 3
Flow Control . . . . . . . . . . . . . . . . 3
Fragmentation . . . . . . . . . . . . . . . . 3
Higher Protocol Layer . . . . . . . . . . . . 3
Type of Service . . . . . . . . . . . . . . . 3
Options . . . . . . . . . . . . . . . . . . . 4
SPECIFICATION . . . . . . . . . . . . . . . . . . . 5
Header Format . . . . . . . . . . . . . . . . . . 5
ATTRIBUTES . . . . . . . . . . . . . . . . . . . . . . 7
Network Addressing . . . . . . . . . . . . . . . . 7 Host Addressing . . . . . . . . . . . . . . . . . 8 Reliability . . . . . . . . . . . . . . . . . . . 9 Flow Control . . . . . . . . . . . . . . . . . . . 10 Fragmentation . . . . . . . . . . . . . . . . . . 11 Higher Protocol Layer . . . . . . . . . . . . . . 12 Type of Service . . . . . . . . . . . . . . . . . 13 Options . . . . . . . . . . . . . . . . . . . . . 14
ADDRESSING OPERATION . . . . . . . . . . . . . . . . 17
FLOW CONTROL OPERATION . . . . . . . . . . . . . . . . 18
FRAGMENTATION OPERATION . . . . . . . . . . . . . . . 20
REFERENCES . . . . . . . . . . . . . . . . . . . . . . 21
[Page i]
Flexible Datagram Protocol April 1979
Preface
This is not a formal protocol specification. As such there are descriptions that are weak and open to interpretation. This is a working document describing the kinds of functions that we feel will be needed in a cable-bus transport level protocol. As our implementation progresses, certain functions may be done away with completely or may be subsumed into other higher level proto- cols. If the implementation is successful, and if there is suf- ficient interest, a less ambiguous version will follow.
A description of the project which will use this protocol
is contained in [1]. Reference 1 is recommended as a closely coupled companion to this IEN.
The protocol was constructed by taking pieces from other
definitions. The Internet Datagram Protocol [2] and the Transmission Control Protocol [3] were used as models both in terms of mechanisms and document format. Many thanks to the ori- ginators of those documents.
Steve Holmgren
[Page ii] April 1979 Flexible Datagram Protocol
Introduction
The Flexible Datagram Protocol (FDP) defines a set of
rules to govern the transport of blocks of data, called da- tagrams, over interconnected cable-bus networks with binary de- grees of reliability, flow control, addressing, and other common transport level protocol mechanisms. FDP uses variable length datagram headers. Each header contains a bit-map specifying the "shape" or attributes of the remaining portion of the header. These attributes are groups of data fields which, if specified, cause the protocol mechanisms referred to above to be invoked. If an attribute is not specified, default processing mechanisms will be invoked and attribute data fields are not placed in the header.
Motivation
A protocol may be viewed as a collection of mechanisms to
support a specific service. Traditional mechanisms include: flow control, addressing, and reliability (e.g. checksums, parity etc.). Newer mechanisms include datagram fragmentation and reassembly to enable their passage through "smaller-sized" net- works, and handling of a datagram security level.
The Flexible Datagram Protocol is motivated by a need to
support a cable bus user community with widely varying transport protocol requirements. The user community ranges from cable- based telephone users who need audio, and soon video, capabili- ties, to the somewhat classic terminal-to-computer and computer- to-computer users.
The FDP meets these needs by allowing a user to dynami-
cally specify the mechanisms to be applied to a datagram. If a user requires a mechanism to support a particular type of data transfer, the price is paid in terms of header overhead and pro- cessing cycles. No penality is paid if a user has no need for a particular mechanism.
Scope
The Flexible Datagram Protocol is intended to provide a
full range of mechanisms to support the communication of packets of data, called datagrams, between low-level nodes of intercon- nected cable-busses. This version defines the selection of the following protocol mechanisms:
1. network addressing,
2. host addressing,
3. data reliability,
4. flow control,
5. datagram fragmentation,
6. higher protocol layer,
7. type of service, and
8. options.
[Page 1]
Flexible Datagram Protocol April 1979
Each of the mechanisms is described below.
Interfaces
On one side, FDP interfaces to a higher level protocol;
possibly a virtual circuit protocol such as Transmission Control Protocol. On the other side it interfaces directly with the lowest level software to transfer a datagram between itself and a cable-bus.
OVERVIEW
This section gives an overview of the framework used to
select the mechanisms to be applied to a datagram and then an overview of the operation of the mechanisms.
Framework
The framework consists of a bit map, called an Attribute
Specification, and a pre-defined sequence in which a fixed-format group of data fields, called attributes, are processed. The Attribute Specification defines whether an attribute has been placed in the header. If the specification indicates that an attribute is in the header, the appropriate number of bytes are handed to the cooresponding protocol mechanism for processing. If an attribute is not in the header, default processing takes place. The next attribute in the pre-defined sequence is then checked. This cycle continues until the Attribute Specification is exhausted.
Protocol Mechanisms
Attributes are processed in the same sequence in which
they are described in this section.
Network Addressing. The Network Address Attribute is
provided to allow users to address sites on a remote network via a gateway or series of gateways which interconnect two or more networks.
The Network Addressing Attribute fields specify the
source and destination networks for the datagram. Since the cable-bus is broadcast in nature, all gateways to other networks will "see" any request for transmission to a remote network. The gateway(s) to the specified network is (are) responsible for accepting the datagram, processing the Attribute specification and performing the appropriate routing of the remaining portion of the datagram to the remote network.
Host Addressing. The Host Addressing Attribute is neces-
sarily provided to allow users to address datagrams to specific destinations.
The Host Addressing Attribute fields specify the source
[Page 2] April 1979 Flexible Datagram Protocol
and destination host numbers for the datagram.
Reliability. The Reliability Attribute is provided to
insure that datagrams are delivered without enroute damage.
The Reliability Attribute has a checksum field and a
length field. The checksum is the complement of the sum of the datagram octets. The length field specifies the number of all octets in the datagram.
Flow Control. The Flow Control Attribute allows a re-
ceiver to control the speed at which a transmitter may send da- tagrams. It uses a sliding window acknowledgement strategy to acknowledge previously received datagrams and to detect duplicate and out-of-sequence datagrams.
Each flow controlled datagram contains a sequence number
ordering the datagram in relation to previous and future da- tagrams, an acknowledgement field acknowledging datagrams previ- ously received by the transmitter, and a window field specifying a range of acceptable per datagram sequence numbers.
Fragmentation. The Fragmentation Attribute is included
to allow the transmission of large (greater than 256 octets) mes- sages as a series of datagrams which are reassembled at the des- tination before delivery to a user. Further, it enables a more direct interconnection of cable bus systems with "small-sized" networks.
The Fragmentation Attribute contains a sequence number
defining the relationship between previous and future fragments of a larger message, a message id relating fragments of a mes- sage, a flags field controlling further fragmentation and last fragment indications, and a life time specification which is decremented as the datagram passes through different internetwork gateways. If the life time field reaches zero, the datagram is assumed to be looping through a sequence of gateways and is dis- carded.
Higher Protocol Layer. The Higher Protocol Layer Attri-
bute specifies the next layer of protocol which is to receive the datagram. It is included to allow the use of FDP by several higher level protocol implementations within the same host. By specifying the next protocol layer within a lower layer, the for- mat of the headers of the higher level protocols are not res- tricted to a common preamble which would be required to demulti- plex messages.
Type of Service. The Type of Service Attribute is in-
cluded to allow the user to give some indication of the priority which is to be applied to a datagram. Initially, the priority may be restricted to linkage of datagrams to the front of inter- nal queues so that immediate attention is given to their process- ing. Later, this may be expanded to the notion of preemptive
[Page 3]
Flexible Datagram Protocol April 1979
allocation of resources, and selection of higher speed, less congested transmission channels.
The Type of Service Attribute contains a field to specify
the priority of the message (lowest to highest), and a field to specify the requested speed of the message (again highest to lowest) within the priority level.
Options. The Options Attribute provides control func-
tions needed or useful in some situations but unnecessary for routine communications. It is also provided to support experi- mental mechanisms that at some point may be elevated to Attribute status.
The Options Attribute includes provisions for special
routing, error messages, protocol version specification, datagram security level, and special low-level signals such as reset.
[Page 4] April 1979 Flexible Datagram Protocol
SPECIFICATION
Header Format
The header contains an Attribute Specification followed
by a variable number of attributes. Each attribute is a group of data fields. This is the format of a header specifying all at- tributes. The brackets attempt to delineate attribute boun- daries.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Att. Spec. ! Att. Spec. ! [ Dest. Net. ! Src. Net ] ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! [ Dest. Host ! Src. Host ] ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! [ Chksum ! Len ] ! [ Ack ! Window ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Seq. Num. ] ! [ Flags ! Life Time ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Frag. Offset ! Msg. Id ] ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ![ Nxt. Proto. ]![Type of Serv.]! [ Options ] ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Data ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that each tick mark corresponds to a bit position.
Attribute Specification: 8 bits (replicated)
Each bit in the Attribute Specification determines wheth-
er an attribute is present in the header. The order in which the attributes are processed corresponds to the bit positions in the Attribute Specification. The order in which the attribute fields are stored in the header is shown in the figure above. Note that the Attribute Specification is repeated in the header so that damage to it may be detected. If a damaged Attribute Specifica- tion is detected, the datagram is discarded.
The figure below shows the correspondence between Attri-
bute Specification bits and attributes.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
!N H R F F P T O!
!A A E L R R O P!
!D D L O G O S T!
+-+-+-+-+-+-+-+-+
NAD: Network Addressing FRG: Fragmentation
HAD: Host Addressing PRO: Next Level Protocol
[Page 5]
Flexible Datagram Protocol April 1979
REL: Reliability TOS: Type of Service
FLO: Flow Control OPT: Options
If a bit is on in the Attribute Specification, the attribute fields will be found in the header. If a bit is off, the attri- bute fields are not present in the header. The following example shows a header with Host Address and Reliability Attributes. The brackets deliniate attribute boundaries.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !0 1 1 0 0 0 0 0!0 1 1 0 0 0 0 0! [ Dest Host ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Src. Host ] ! [ Chksum ! Len ] ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Data ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[Page 6] April 1979 Flexible Datagram Protocol
ATTRIBUTES
Network Addressing: (Bit 0)
The Network Addressing Attribute has a Destination and a
Source Network field.
If not specified the datagram is not routed outside the
local network. See Addressing Operation below.
Dest. Net. (Destination Network): 8 bits
Contains the number of the network to
which the datagram is to be routed.
Src. Net. (Source Network): 8 bits
Contains the number of the network from
which the datagram originated.
[Page 7]
Flexible Datagram Protocol April 1979
Host Addressing: (Bit 1)
The Host Addressing Attribute has a Destination and
Source Host field.
If not specified, the datagram is a broadcast message to
all hosts. See Addressing Operation below.
Dest. Host. (Destination Host): 16 bits
Contains the number of the host to which
the datagram is to be routed.
Src. Host (Source Host): 16 bits
Contains the number of the host which
originated the datagram.
[Page 8] April 1979 Flexible Datagram Protocol
Reliability: (Bit 2)
The Reliability Attribute contains a checksum and a
length field.
If not specified, the datagram is assumed to be undamaged
and its length is obtained from the hardware interface.
Chksum (Checksum): 8 bits
The Checksum field contains the one's
complement of the one's complement byte
sum of the datagram. The Checksum field
is set to zero while the checksum is
being computed.
Len. (Length): 8 bits
The Length field specifies the number of
octets in the datagram. This field
counts all header and data octets.
[Page 9]
Flexible Datagram Protocol April 1979
Flow Control: (Bit 3)
The Flow Control Attribute contains an Acknowledgement
field, a Window field, and a Sequence Number field.
If not specified, the datagram is not subject to flow
control considerations. See Flow Control Operation below.
Ack. (Acknowledgement): 8 bits
The Acknowledgement field contains a
sequence number greater than or equal
(cyclically) to the sequence numbers of
all successfully received datagrams.
Window: 8 bits
The Window field contains the number of
datagrams beyond the sequence number in
the Acknowledgement field which the
sender of the datagram is willing to
accept.
Seq. Num. (Sequence Number): 16 bits
The Sequence Number field contains the
sequence number of the datagram.
[Page 10] April 1979 Flexible Datagram Protocol
Fragmentation: (bit 4)
The Fragmentation Attribute contains a Flags field, a
Life Time field, a Fragment Offset field, and a Message iden- tifer.
If the Fragmentation Attribute is not specified, gateways
are free to fragment the datagram into smaller messages if re- quired by the destination network. See Fragmentation Operation below.
Flags: 8 bits
Various Control Flags.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
!0 D M 0 0 0 0 0!
!0 F F 0 0 0 0 0!
+-+-+-+-+-+-+-+-+
Bit 0: reserved, must be zero.
Bit 1: Don't Fragment This Datagram (DF).
Bit 2: More Fragments Field (MF).
Bit 3: Unused, must be zero.
Bit 4: Unused, must be zero.
Bit 5: Unused, must be zero.
Bit 6: Unused, must be zero.
Bit 7: Unused, must be zero.
Life Time: 8 bits
This field is decremented for each hop
taken through the internetwork system.
If it decrements to zero, the datagram is
presumed to be in an internetwork loop
and should be discarded.
Frag. Offset (Fragmentation Offset): 16 bits
This field relates the datagram to previ-
ous and future fragments. Each fragment
datagram is given a sequence number.
This field orders the fragment in rela-
tion to other fragments.
Msg. Id. (Message Identifer): 16 bits
This field is an arbitrary identifer for
the message that was fragmented. Each
message fragment contains the identifer
to be used as an aid in reassembling the
fragments of the message.
[Page 11]
Flexible Datagram Protocol April 1979
Next Higher Level Protocol: (bit 5)
This attribute contains the Next Protocol field.
If this attribute is not specified, a default higher lev-
el protocol receives the datagram.
Nxt. Proto. (Next Protocol): 8 bits
This field contains an identifier of the
next higher level protocol which is to
receive that contents of the data portion
of the datagram.
[Page 12] April 1979 Flexible Datagram Protocol
Type of Service: (bit 6)
This attribute contains the Type of Service field. This
field, if present, defines the priority and relative speed re- quirements within the priority which the sender wishes to attach to the datagram.
If not specified, no special handling is given to the
datagram.
Type of Serv. (Type of Service): 8 bits
The Type of Service field contains two
sub-fields with define the priority of
the datagram and the speed which is to be
applied to the datagram.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
! Pri ! Spd !
+-+-+-+-+-+-+-+-+
Priority Speed
0 - Lowest 0 - Slowest
31 - Highest 7 - Fastest
[Page 13]
Flexible Datagram Protocol April 1979
Options: (bit 7)
This attribute contains a variable number of fields. The
format is an option-type octet, an option-length octet, and the actual option-data octets. There are two special case options which have only the option-type octet (End of Options List and Nop).
The option-length octet includes the option-type octet
and the option-length octet in the octet count of the option length.
The option-type octet can be viewed as having three
fields:
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
If not specified, no special option processing is re-
quested.
The following options are defined:
Class Number Length Description
0 0 - End of Option List.
0 1 - No Operation
0 2 4 S/P/T. Security, Precidence, TCC
0 3 var. Source Routine.
0 31 4 Reset
0 30 var. Status
1 1 var. General Error Report.
2 4 var. Internet Timestamp
2 5 var. Satellite Timestamp
Specific Option Definitions
End of Option List. This option indicates the end of
option list. It is always used to terminate the list of all options.
+--------+
!00000000!
+--------+
No Operation. This option may be used between options to
[Page 14] April 1979 Flexible Datagram Protocol
align the beginning of a subsequent option on a 32 bit boundary.
+--------+
!00000001!
+--------+
S/P/T. This option provides a way for AUTODIN II hosts
to send security, precedence, and TCC (closed user groups) param- eters through networks whose transport leader does not contain fields for this information.
+--------+--------+--------+--------+
!00000010!00000100!Prec!Sec! TCC !
+--------+--------+--------+--------+
Precedence: 4 bits
Specifies one of 16 levels of precedence.
Security: 4 bits
Specifies one of 16 levels of security.
Transmission Control Code (TCC): 8 bits
Provides a means to compartmentalize traffic
and define controlled communities of interest
among subscribers.
Source Routing. The source routing option provides a
means for the source of a datagram to supply routing information to be used by gateways in forwarding the datagram to the destina- tion.
A source route is composed of a series of internet ad-
dresses. The pointer is initially zero, which indicates the first octet of the source route. The segment is routed to the address in the source route indicated by the pointer. At the internet module the pointer is advanced to the next address in the source route. This routing and pointer advancement is re- peated until the source address is exhausted. At that point, the destination may have been reached, if not, the protocol module must attempt to route the packet to the destination in the desti- nation address field by the ordinary routing procedure.
+--------+---------+--------+--------+-----/ /-----+
!00000011! length ! pointer! source route !
+--------+---------+--------+-------------/ /------+
Reset. The reset option allows a host on a network to
signal other hosts that its network operations have been restart- ed. The data field contains the address of the restarted host.
+--------+--------+--------+--------+
!00011111!00000100! Host Address !
+--------+--------+--------+--------+
[Page 15]
Flexible Datagram Protocol April 1979
Status. The status option allows a host to transmit
status information to a remote host. The conditions for elicit- ing the information and the content of the data fields are net- work dependent.
+--------+--------+---------+--------/ /------+
!00011110! length ! Status Info !
+--------+--------+---------+-------/ /-------+
General Error Report. The general error report is used
to report an error detected in the processing of a datagram to the originator of the datagram. The "err code" indicates the type of error detected and the "id" is copied from the message id field of the datagram, if it exists. Additional octets of error information may be present depending on the error code.
Err Code:
0 - Undetermined Error Used when no in-
formation is available about the type of
error or the error does not fit in any
defined class.
No error codes for specific classes have
been defined.
+--------+--------+--------+--------+----/ /------+
!00100001! length !err code! id ! !
+--------+--------+--------+--------+-----/ /-----+
Internet Timestamp. No information is available on the
specific format of Timestamps.
+--------+--------+--------+--------+-----/ /-----+
!01000100! length ! !
+--------+--------+--------+--------+----/ /------+
Satellite Timestamp. No information is available on the
specific format of Timestamps.
+--------+--------+---------+--------+---/ /-----+
!01000101! length ! !
+--------+--------+---------+--------+---/ /-----+
[Page 16] April 1979 Flexible Datagram Protocol
Addressing Operation
A distinction is made between names, addresses, and
routes [4]. A name indicates what we seek. An address indicates where it is. A route indicates how to get there. The Flexible Datagram Protocol deals only with addresses. It is the task of higher level protocols to make the mapping from names to ad- dresses. It is the task of lower level procedures (i.e. internet gateways) to make the mapping from addresses to routes.
When the Network Address Attribute is specified, the net-
work fields have values obtained from reference [5]. When a mes- sage is transmitted to the cable-bus, all internet gateways watch for messages with destination networks to which they have access. If a match is found, the remaining attributes of the header are processed according to specified convention. The datagram is then passed along the route to the remote network after possible fragmentation.
When the Host Address Attribute is specified, hosts com-
pare the destination host field with their address. If a match is found, and the destination network number (if specified) matches the local network number, the host processes the remain- ing Attributes in the header of the datagram and passes the data portion of the datagram to the next higher level protocol.
[Page 17]
Flexible Datagram Protocol April 1979
Flow Control Operation
Flow control regulates the transfer of data. Each re-
ceiver controls the amount of data a transmitter may send. Each receiver can dynamically update this control without loss or duplication of data.
Each datagram containing the Flow Control Attribute is
assigned a sequence number. The sequence numbers range from 0 to 65535 and are used cyclically; i.e. 0 follows 65535. The se- quence number for each datagram is placed in the header of each outgoing datagram containing the Flow Control Attribute. The first sequence number used is zero.
The Ack field contains the sequence number of the last
datagram accepted by the transmitter. The receiver can consider all sequence numbers (cyclically) less than or equal to the number in the Ack field to have been received by the other end and can free buffers accordingly.
The Window field contains the number of datagrams, beyond
that denoted by the Ack field, the transmitter is currently prepared to accept. The datagrams will have sequence numbers (Ack + 1) through (Ack + Window) cyclically calculated. A window value of zero indicates that the transmitter is not prepared to accept any datagrams until further notice. This does not mean that a transmitter may not send a datagram. It means that re- transmission intervals should be increased significantly.
The sending of a datagram with a non-zero window does not
irrevocably commit a transmitter to accept that number of da- tagrams. Changing conditions may cause an untimely reduction in the window size. These conditions may prevail at the same time other transmitters are sending datagrams (for which they were given a non-zero window) to the afflicted host. Sequences of this kind can generate duplicate and discarded datagrams.
A receiver must be able to detect and discard duplicate
datagrams. In order for duplicate detection to be possible, the Window field must not contain a value greater than half the se- quence number space (i.e. 32768) and no more than 32768 datagrams may be unacknowledged at any time. A receiver may identify du- plicate datagrams as those with sequence numbers in the range
((last acknowledged) - 32767) through (last acknowledged)
A receiver should discard any datagrams with sequence numbers in this range.
Sending a window size greater than 32768 is prohibited.
Receiving a window size greater than 32768 should be adjusted to 32768.
Certain combinations of events can generate the receipt
[Page 18] April 1979 Flexible Datagram Protocol
of datagrams out of sequence. A receiver may discard out-of- sequence datagrams or it may save them for later insertion into the proper sequence.
It is possible for datagrams to arrive for which a window
does not currently exist. A receiver may discard these da- tagrams.
A transmitter should be aware of these situations and
have sufficient mechanisms to retransmit a datagram after a rea- sonable time has elapsed. Various strategies for defining "rea- sonable" are under study.
The simplest strategy a receiver can employ is to accept
only the next datagram in sequence and discard all others. This works if the receiver employs a somewhat linear window policy.
Acknowledgements should be sent as soon as possible.
They may be carried by datagrams flowing the other way. If no datagram is available for carrying the response after a "reason- able" time a datagram containing appropriate Address Attributes and the Flow Control Attribute should be artifically constructed and transmitted. It may be reasonable to employ a time-out mechanism controlling generation of "acknowledgement only" da- tagrams.
[Page 19]
Flexible Datagram Protocol April 1979
Fragmentation Operation
Fragmentation of a datagram may be necessary when it ori-
ginates in a remote network that allows a large datagram size and must traverse the local network which limits datagrams to a smaller size.
The Message Identification field is used together with
the source and destination address (if present), and the Next Protocol field (if present) to identify fragments for reassembly.
The More Fragments flag bit (MF) is set if the datagram
is not the last fragment. The Fragment Offset field identifies the fragment number relative to the beginning of the original unfragmented datagram; zero is the first fragment, one the second and so on.
When fragmentation occurs, options are generally not
copied, but remain with the first fragment. Some options, such as source routing, must be copied.
The fields which may be affected by fragmentation in-
clude:
(1) options field
(2) more fragments flag
(3) fragment offset
(4) checksum (if present)
If the Don't Fragment flag (DF) bit is set then fragmen-
tation of the datagram is not permitted, although it may be dis- carded. This is used where the receiving host does not have resources to reassemble fragments.
The choice of Message 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 frag- ments judges fragments to belong ot the same datagram if they have the same source, destination, Next Higher Level Protocol (if present), and Message Identifier. Thus, the sender must choose the Identifier to be unique for this source and destination pair and protocol over the time the datagram (or any fragment of it) could be alive in the internetwork.
It is appropriate for some higher level protocols to
choose the identifier. For example, TCP modules may retransmit an identical TCP segment, and the probability for correct recep- tion would be enhanced if the retransmission carried the same identifier as the original transmission since fragments of either datagram could be used to reconstruct a correct TCP segment.
[Page 20] April 1979 Flexible Datagram Protocol
REFERENCES
[1] Skelton, A.P., Holmgren, S.F., "The MITRE
Cablenet Project", IEN 96, April 1979
[2] Information Sciences Institute, "Internet Datagram Protocol",
Version 4, IEN 80, February 1979
[3] Information Sciences Institute, "Transmission Control Protocol",
Version 4, IEN 81, February 1979
[4] Shoch, J., "A Note On Inter-Network Naming, Addressing, and
Routing," Xerox Palo Alto Research Center, IEN 19, January 1978.
[5] Postel, J., "Assigned Numbers," RFC 750, NIC 45500,
26 September 1978.
[Page 21]