IEN: 97


                            Version 1

                           April 1979

                          prepared for

                  Defense Communication Agency
                     WWMCCS ADP Directorate
              Command and Control Technical Center
                    11440 Isaac Newton Square
                        Reston, Va. 22090


                        MITRE Corporation
                   1820 Dolley Madision Blvd.
                        McLean Va. 22102

April 1979                             Flexible Datagram Protocol

                        TABLE OF CONTENTS


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


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


        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


        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.


        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.


        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


        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.


        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

        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

        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"

        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-

        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

        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


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-

                       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


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

        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-

        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

        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

        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

        The option-length octet includes  the  option-type  octet
and  the  option-length  octet  in  the octet count of the option

        The  option-type  octet  can  be  viewed  as having three

                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-

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


        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.


        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-

        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

        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

        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-

        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-

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

                (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


[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]