IEN 186                                               1 June 1981







                      PROPOSED DCEC IP SPECIFICATION





                               prepared by

                            Mary M. Bernstein

                      System Development Corporation
                           2500 Colorado Avenue
                          Santa Monica, CA 90406
                              (213) 820-4111












                                 Abstract

     This document specifies the Internet Protocol (IP) which supports
     the  interconnection  of communication subnetworks.  The document
     includes an introducion to IP with a model of operation, a defin-
     ition  of services provided to users, and a description architec-
     tural  and  environmental  requirements.   The  protocol  service
     interfaces  and  mechanisms are specified using an abstract state
     machine model.

                                        System Development Corporation
     1 June 1981                                               IEN 186


     FOREWORD





     This document has been submitted to the DCEC for consideration as
     a  standard specification of the Internet Protocol.  The document
     incorporates  the  organization  and   specification   techniques
     presented in the DCEC Protocol Specification Guidelines.  This is
     a preliminary version; a revised version is  to  be  released  in
     December  1981.   Any  comments  regarding  completeness and con-
     sistency or suggestions for improvement of this document are wel-
     comed.


                                   Mary M. Bernstein

                                   System Development Corporation
                                   2500 Colorado Avenue
                                   Santa Monica, CA 90406
                                   (213) 820-4111

                                   ARPANET: brnstein@dti

                                 CONTENTS


     1.  OVERVIEW.................................................   1
         1.1  Scenario............................................   4

     2.  DESCRIPTION OF SERVICES PROVIDED TO UPPER LAYERS.........   6
         2.1  Datagram Service....................................   6
         2.2  Virtual Network Services............................   6
         2.3  Error Reporting Service.............................   7

     3.  UPPER LAYER SERVICE/INTERFACE SPECIFICATION..............   8
         3.1  Interaction Primitives..............................   8
              3.1.1   Service Request Primitives   8
              3.1.2   Service Response Primitives   9
         3.2  Abstract Machine Definition of Upper Level Services
              and Interaction Discipline..........................  10
              3.2.1   Machine Identifier  10
              3.2.2   State Diagram  11
              3.2.3   State Vector  11
              3.2.4   State Machine Data Structures  11
              3.2.5   Event List  12
              3.2.6   Events and Actions  12

     4.  DESCRIPTION OF LOWER LAYER SERVICE REQUIREMENTS..........  14
         4.1  Data Transfer.......................................  14
         4.2  Error Reporting.....................................  14

     5.  LOWER LAYER SERVICE/INTERFACE SPECIFICATION..............  15
         5.1  Interaction Primitives..............................  15
              5.1.1   Service Request Primitives  15
              5.1.2   Service Response Primitives  16
         5.2  Abstract Machine Definition of Lower Level Services
              and Interaction Discipline..........................  16
              5.2.1   Machine Identifier  16
              5.2.2   State Diagram  17
              5.2.3   State Vector  17
              5.2.4   State Machine Data Structures  17
              5.2.5   Event List  17
              5.2.6   Events and Actions  18

     6.  MECHANISM SPECIFICATION..................................  19
         6.1  Overview of IP Mechanisms...........................  19
              6.1.1   Routing Mechanism  19
              6.1.2   Fragmentation and Reassembly  21
              6.1.3   Checksum  22
              6.1.4   Time To Live  23
              6.1.5   Type of Service  23
              6.1.6   Data Options  23
              6.1.7   Error Report Datagrams  24
         6.2  Internet Protocol Header Format.....................  26
              6.2.1   Version  26

              6.2.2   Internet Header Length  26
              6.2.3   Type of Service  27
              6.2.4   Total Length  27
              6.2.5   Identification  27
              6.2.6   Flags  28
              6.2.7   Fragment Offset  28
              6.2.8   Time to Live  28
              6.2.9   Protocol  28
              6.2.10  Header Checksum  29
              6.2.11  Source Address  29
              6.2.12  Destination Address  29
              6.2.13  Padding  29
              6.2.14  Options  29
              6.2.15  Specific Option Definitions  31
              6.2.16  Error Report Datagrams  33
         6.3  Extended State Machine Representation...............  35
              6.3.1   State Machine Identification  35
              6.3.2   State Machine Diagram  35
              6.3.3   State Vector  36
              6.3.4   State Machine Data Structures  37
              6.3.5   Event List  39
              6.3.6   State Machine Events and Actions  39

     7.  EXECUTION ENVIRONMENT REQUIREMENTS.......................  72
         7.1  Inter-process communication.........................  72
         7.2  Timing..............................................  72

     8.  BIBLIOGRAPHY.............................................  73

     9.  GLOSSARY.................................................  74

                                        System Development Corporation
     1 June 1981                    -1-                        IEN 186


     1.  OVERVIEW

     This document specifies the Internet Protocol (IP) which supports
     the  interconnection  of communication subnetworks.  The document
     introduces the Internet Protocol's role and purpose, defines  the
     services  provided  to users, and specifies the mechanisms needed
     to support those services.  This document also defines  the  ser-
     vices  required  of the lower protocol layer, describes the upper
     and lower interfaces, and outlines the  operating  system  primi-
     tives  needed  for  implementation.   In  addition, a glossary of
     terms and a set of appendices discussing certain  aspects  of  IP
     are included.  The reader is assumed to be familiar with the DCEC
     Architecture Report which presents a protocol architecture  model
     for  DoD  communication  services[1].  This document incorporates
     the organization and specification techniques  presented  in  the
     DCEC Protocol Specification Guidelines[2].

     The Internet Protocol is designed to interconnect packet-switched
     communication  subnetworks to form an internetwork.  IP transmits
     blocks of data, called internet datagrams, from sources to desti-
     nations  throughout  the  internet.  Sources and destinations are
     hosts located on either the same subnetwork or connected  subnet-
     works.   IP  is  purposely  limited in scope to provide the basic
     functions necessary to deliver a block of  data.   Each  internet
     datagram is an independent entity unrelated to any other internet
     datagram.  IP does not create connections  or  logical  circuits.
     IP  has  no mechanisms to promote data reliability, flow control,
     sequencing, or other services commonly found in host-to-host pro-
     tocols.


                +------+ +-----+ +------+        +-----+
                |Telnet| | FTP | | EFTP |  ...   |     |
                +------+ +-----+ +------+        +-----+
                      |   |         |               |
                     +-----+     +-----+         +-----+
                     | TCP |     | UDP |   ...   |     |
                     +-----+     +-----+         +-----+
                        |           |               |
                     +--------------------------------+
                     |     HOST INTERNET PROTOCOL     |
                     +--------------------------------+
                                    |
                        +------------------------+
                        |  Subnetwork Protocol   |
                        +------------------------+

                   1. Example Host Protocol Hierarchy


     This document specifies a host  IP.   In  the  DoD  architectural
     model,  a  host  IP resides between transport layer and the lower

                                        System Development Corporation
     1 June 1981                    -2-                        IEN 186


     network sublayer in each internet host.  In each gateway, a  site
     interconnecting  two  or more subnets, an IP resides above two or
     more subnetwork entities.  In a gateway, IP is closely coupled to
     the  Gateway  to  Gateway Protocol (GGP) to form a gateway IP.  A
     gateway IP supports many of the same functions as a host IP,  but
     provides  additional  services  such  as  maintenance  of current
     internet topology data.  Throughout the remainder  of  the  docu-
     ment, a host IP is simply referred to as IP.

                         GATEWAY INTERNET PROTOCOL
                  +-----------------------------------+
                  |      Gateway-Gateway Protocol     |
                  +- - - - - - - - - - - - - - - - - -+
                  |         Internet Protocol         |
                  +-----------------------------------+
                     |            |                |
               +---------+   +---------+        +---------+
               |subnet 1 |   |subnet 2 |  ...   |subnet i |
               | protocol|   | protocol|        | protocol|
               +---------+   +---------+        +---------+
                    |            |                 |
                 ARPANET      local net          public net


                  2. Example Gateway Protocol Hierarchy


     A protocol in an upper layer passes data to IP for delivery.   IP
     packages  the  data  as an internet datagram and passes it to the
     local subnetwork protocol for transmission across the local  sub-
     net.   If  the  destination host is on the local subnet, IP sends
     the datagram through the subnet directly to that  host.   If  the
     destination  host is on a connected subnet, IP sends the datagram
     to an appropriate gateway.   The  gateway,  in  turn,  sends  the
     datagram  through  the next subnet to the destination host, or to
     another gateway.

     Thus, datagrams move from one IP module  to  another  through  an
     interconnected  set  of  subnetworks  until  the  destination  is
     reached.  The sequence of IP modules  handling  the  datagram  in
     transit  is  called  the gateway route. The gateway route is dis-
     tinct from the lower level node-to-node route supplied by a  par-
     ticular  subnetwork.   The gateway route is based on the destina-
     tion internet address.  The IP modules  share  common  rules  for
     interpreting internet addresses to perform internet routing.

     In transit, datagrams may traverse  a  subnetwork  whose  maximum
     packet  size is smaller than the size of the datagram.  To handle
     this, IP provides fragmentation and reassembly  mechanisms.   The
     gateway  at  the  smaller-packet  subnet  fragments  the original
     datagram into pieces, called datagram fragments, small enough for
     transmission.   The IP module in the destination host reassembles

                                        System Development Corporation
     1 June 1981                    -3-                        IEN 186


     the datagram fragments to reproduce the original datagram.

     IP can support a diverse set of upper layer protocols (ULPs).   A
     transport  protocol with real-time requirements, such as the Net-
     work Voice Protocol (NVP), can make use of IP's datagram  service
     directly.    A  transport  protocol  providing  ordered  reliable
     delivery, such as TCP, can build additional mechanisms on top  of
     IP's  basic datagram service.  Also, IP's delivery service can be
     customized in some ways to suit the special  needs  of  an  upper
     layer protocol.  For example, a pre-defined gateway route, called
     a source route, can be supplied for an individual datagram.  Each
     IP  module  forwards  the  datagram according to the source route
     instead of using only the independent routing mechanism.

     The Internet Protocol shares a common history with the  Transmis-
     sion Control Protocol, first described in [3].  Later, IP and TCP
     were separated and specified as two distinct protocols in [4] and
     [5].   A  wide  range  of  technical, legal, and political issues
     associated with subnetwork interconnection is presented  in  [6].
     Alternative  approaches  to  internetting,  including  the  CCITT
     Recommendation X.75 and the PUP architecture, are introduced  and
     compared  in in [7], [8], and [9].  Certain aspects of fragmenta-
     tion and routing are are discussed in [10], and [11].   [12]  and
     [13]  contain  current address mappings and assigned numbers used
     in network protocol implementations.

                                        System Development Corporation
     1 June 1981                    -4-                        IEN 186


     1.1  Scenario

     The following scenario illustrates the  model  of  operation  for
     transmitting a datagram from one upper layer protocol to another.
     The scenario is purposely simple so that IP's basic operation  is
     not  obscured  by  the  details of interface parameters or header
     fields.

     A ULP in host A is to send data to a peer protocol in host  B  on
     another  subnetwork.   In  this  case, the source and destination
     hosts are on subnetworks directly connected by a gateway.

            HOST A                                    HOST B
        ----------------                        ------------------
        |   Sending    |                        |    Receiving   |
        | Upper Layer  |                        |    Upper Layer |
        |  Protocol    |        GATEWAY         |     Protocol   |
        |      \       |   ------------------   |     /          |
        |    IP Module |   |   IP Module    |   |  IP Module     |
        |        \     |   |    /     \     |   |   /            |
        |        SNP-1 |   | SNP-1    SNP-2 |   | SNP-2          |
        ----------------   ------------------   ------------------
                   \          /        \          /
                   Local Subnet 1       Local Subnet 2

                       Basic Model of Operation




      a.  The sending ULP passes its data to the IP module, along with
          the destination internet address and other parameters.

      b.  The IP module prepares an IP header and attaches  the  ULP's
          data  to  form  an  internet  datagram.  Then, the IP module
          determines a local subnetwork address from  the  destination
          internet  address.   In  this case, it is the address of the
          gateway  to  the  destination  subnetwork.    The   internet
          datagram  along  with  the local subnet address is passed to
          the local subnetwork protocol (abbreviated as SNP).

      c.  The SNP creates a local subnetwork header and attaches it to
          the  datagram  forming  a  subnetwork  packet.  The SNP then
          transmits the packet across the local subnet.

                                        System Development Corporation
     1 June 1981                    -5-                        IEN 186



                       <========= subnetwork packet =========>

                       +------+---------+---------/ /--------+
                       |  *   |    *    |    *               |
                       +--:---+----:----+----:---/ /---------+
                          :        :         :
                          :        :         :
                          :        :      ULP data
                          :     IP header
                          :
                       subnetwork header


      d.  The packet arrives at the gateway connecting the  first  and
          second  subnetworks.  The SNP of the first subnet strips off
          the local subnetwork header and passes the remainder to  the
          IP module.

      e.  The IP  module  determines  from  the  destination  internet
          address in the IP header that the datagram is intended for a
          host in the second subnet.  The IP  module  then  derives  a
          local  subnetwork  address  for  the destination host.  That
          address is passed along with the datagram to the SNP of  the
          second subnetwork for delivery.

      f.  The second subnet's SNP builds a local subnetwork header and
          appends the datagram to form a packet for the second subnet-
          work.  That packet is transmitted across the  second  subnet
          to the destination host.

      g.  The SNP of the destination host strips off the local subnet-
          work  header  and  hands  the  remaining  datagram to the IP
          module.

      h.  The IP module determines that the datagram is  bound  for  a
          ULP within this host.  The data portion of the datagram, the
          source internet address, and  other  option  parameters  are
          passed to the ULP.

     Delivery of data across the internet is complete.

                                        System Development Corporation
     1 June 1981                    -6-                        IEN 186


     2.  DESCRIPTION OF SERVICES PROVIDED TO UPPER LAYERS

     This section describes the services offered by the Internet  Pro-
     tocol to upper layer protocols (ULPs).  The goals of this section
     are to provide the  motivation  for  protocol  mechanisms  and  a
     definition of the functions provided by this protocol.

     The services provided by IP are:

     o intact internet datagram service

     o virtual network service

     o error reporting service


     A description of each service follows.

     2.1  Datagram Service

     The Internet Protocol shall provide a  datagram  service  between
     homogeneous  upper layer protocols in an internet environment.  A
     datagram service is characterized by data delivery to the  desti-
     nation with non-zero probability; some data may possibly be lost.
     Also, a  datagram  service  does  not  necessarily  preserve  the
     sequence in which data is supplied by the source upon delivery at
     the destination.

     IP shall deliver received data to a destination ULP in  the  same
     form  as sent by the source ULP.  IP shall discard datagrams when
     insufficient resources are available for processing.  IP does not
     detect datagrams lost or discarded by the subnetwork layer.

     As part of the delivery service, IP insulates upper layer  proto-
     cols  from  subnetwork specific characteristics.  For example, IP
     maps internet addresses supplied by  ULPs  into  local  addresses
     used  by  the  local  subnetwork.  Also, IP hides any packet-size
     restrictions of subnetworks along the  transmission  path  within
     the internet.


     2.2  Virtual Network Services

     IP shall provide to upper layer protocols the ability  to  select
     virtual  network service parameters.  IP shall provide a standard
     command set for the ULPs to indicate the services desired.  Thus,
     the  ULPs  can  tune  certain properties of IP and the underlying
     subnetworks to customize the transmission  service  according  to
     their needs.

     The virtual network parameters fall into two categories:  service
     quality   parameters   and   service  options.   Service  quality

                                        System Development Corporation
     1 June 1981                    -7-                        IEN 186


     parameters influence the transmission  service  provided  by  the
     subnetworks;   service  options are additional functions provided
     by IP.  A brief description of each follows:

     o Service Quality Parameters

         - Precedence  :  attempts  preferential  treatment  for  high
           importance datagrams

         - Transmission  Mode  :  datagram  vs.  stream.  Stream  mode
           attempts  to  minimize  delay  and delay dispersion through
           reservation of network resources

         - Reliability : attempts to minimize data loss and error rate

         - Speed : attempts prompt delivery

         - Resource Tradeoff : indicates relative importance of  speed
           vs. reliability.

     o Service Options

         - Security  Labelling  :  identifies  datagram  for  compart-
           mented hosts

         - Source Routing : selects set of gateway IP modules to visit
           in transit

         - Route Recording : records gateway IP modules encountered in
           transit

         - Stream Identification : names reserved resources  used  for
           stream service

         - Time Stamping : records time information

         - Don't Fragment : marks a datagram as an indivisible unit


     2.3  Error Reporting Service

     IP shall provide error reports to the upper layer protocols indi-
     cating   errors  detected  in  providing  the above services.  In
     addition, certain errors detected by lower layer protocols  shall
     be passed to the ULPs.  These reports indicate several classes of
     errors including invalid arguments, insufficient  resources,  and
     transmission errors.  The errors that IP must report to ULPs have
     not been defined.  IP's  error  reporting  responsibilities  need
     further examination.

                                        System Development Corporation
     1 June 1981                    -8-                        IEN 186


     3.  UPPER LAYER SERVICE/INTERFACE SPECIFICATION

     This section specifies the IP services provided  to  upper  layer
     protocols  and  the  interface  through  which these services are
     accessed.  The first part defines the interaction primitives  and
     interface  parameters  for  the upper interface.  The second part
     contains the abstract machine specification of  the  upper  layer
     services and interaction discipline.


     3.1  Interaction Primitives

     An interaction primitive  defines  the  purpose  and  content  of
     information  exchanged  between  two protocol layers.  Primitives
     are grouped into two classes based on the direction  of  informa-
     tion  flow.  Information passed downward, in this case from a ULP
     to IP, is called a service request primitive.  Information passed
     upward,  in  this  case  from  IP  to  a ULP, is called a service
     response primitive.  Interaction primitives  need  not  occur  in
     pairs.   That  is,  a  request  does  not  necessarily  elicit  a
     "response"; a "response" may occur independently of a request.

     The information associated with an  interaction  primitive  falls
     into   two  categories:  parameters  and  data.   The  parameters
     describe the data and indicate how the data  is  to  be  treated.
     The  data is not examined or modified.  The format of the parame-
     ters and data  is  implementation  dependent  and  therefore  not
     specified.

     A given IP implementation may have slightly different interaction
     primitives  imposed by the execution environment or system design
     factors.  In those cases,  the  primitives  can  be  modified  to
     include  more information or additional primitives can be defined
     to satisfy system requirements.  However, all IPs must provide at
     least  the  interaction  primitives  specified below to guarantee
     that all IP implementations can support the same protocol hierar-
     chy.


     3.1.1  Service Request Primitives

     A single service request primitive supports  IP's  datagram  ser-
     vice, the SEND primitive.

     3.1.1.1  SEND

     The SEND primitive contains complete control information for each
     unit  of data to be delivered.  IP accepts in a SEND at least the
     following information:

     o source address - internet address of ULP sending data

                                        System Development Corporation
     1 June 1981                    -9-                        IEN 186


     o destination address - internet address of ULP to receive data

     o protocol - name of the recipient ULP

     o type of service  indicators  -  relative  transmission  quality
      associated with unit of data

         - precedence - one of five levels : (P1, P2,  P3,  P4,  P5  )
                        where P1 <= P2 <= P3 <= P4 <= P5

         - reliability - one  of  four  levels  :  (R1,  R2,  R3,  R4)
                         where R1 <= R2 <= R3 <= R4

         - speed - one of two levels : (S1, S2) where S1 <= S2

         - resource trade-off  -  speed  or  reliability  :  (T1,  T2)
                                where T1 = speed, T2 = reliability

         - transmission mode - stream or datagram  :  (M1,  M2)  where
                               M1 = stream, M2 = datagram

     o identifier - value distinguishing this  portion  of  data  from
      others sent by this ULP.

     o don't fragment indicator - flag showing whether IP can fragment
      data to accomplish delivery

     o time to live - value in seconds indicating maximum lifetime  of
      data within the internet

     o data length - size of data being transmitted

     o option data - options requested by  ULP  from  following  list:
      security, source routing, return routing, stream identification,
      or time stamp. (See section 6.2.14.)

     o data - present when data length is greater than zero.

     3.1.2  Service Response Primitives

     A single service response primitive supports IP's  datagram  ser-
     vice, the DELIVER primitive.

     3.1.2.1  DELIVER

     The DELIVER primitive contains the data passed by a source ULP in
     a  SEND,  along  with  addressing, quality of service, and option
     information.  IP passes in  a  DELIVER  at  least  the  following
     information:

     o source address - internet address of sending ULP

                                        System Development Corporation
     1 June 1981                   -10-                        IEN 186


     o destination address - internet address of the recipient ULP

     o protocol - name of recipient ULP as supplied by the sending ULP

     o type of service  indicators  -  relative  transmission  quality
      associated with unit of data

         - precedence - one of five levels : (P1, P2,  P3,  P4,  P5  )
                        where P1 <= P2 <= P3 <= P4 <= P5

         - reliability - one  of  four  levels  :  (R1,  R2,  R3,  R4)
                         where R1 <= R2 <= R3 <= R4

         - speed - one of two levels : (S1, S2) where S1 <= S2

         - resource trade-off  -  speed  or  reliability  :  (T1,  T2)
                                where T1 = speed, T2 = reliability

         - transmission mode - stream or datagram  :  (M1,  M2)  where
                               M1 = stream, M2 = datagram

     o data length - number of octets of received data (possibly zero)

     o option data - options requested by source  ULP  from  following
      list: security, source routing, return routing, stream identifi-
      cation, or time stamps. (See section 6.2.14.)

     o data - present when data length is greater than zero.

     In addition, a DELIVER may contain error reports from  IP  either
     together with parameters and data listed above, or, independently
     of that information.  This area  needs  further  examination  and
     definition.

     3.2  Abstract Machine Definition of Upper Level Services and
          Interaction Discipline

     The abstract machine defines the behavior of the  entire  service
     machine  from  the  perspective  of the upper layer protocol.  An
     abstract machine definition is composed of a machine  identifier,
     a  state  diagram,  a  state vector, a set of data structures, an
     event list, and an events and actions correspondence.

     3.2.1  Machine Identifier

     Each upper interface state machine is uniquely identified by  the
     four values:

     o source address

     o destination address

                                        System Development Corporation
     1 June 1981                   -11-                        IEN 186


     o protocol

     o identifier

     3.2.2  State Diagram

     The upper interface state machine has a single state which  never
     changes.  No diagram is needed.


     3.2.3  State Vector

     The upper interface state machine has a single state which  never
     changes.  No state vector is needed.


     3.2.4  State Machine Data Structures

     No data  structures  are  used  for  the  upper  interface  state
     machine.   However, the following abbreviations are used to refer
     to parameters of the interaction primitives:

          S = source internet address
          D = destination internet address
          P = protocol identifier
          TOS = type of service where
                    p(i) = one of the precedence levels (P1, P2, P3, P4, P5)
                       (Note: read p(i) as "p sub i")
                    r(i) = one of the reliability levels (R1, R2, R3, R4)
                    s(i) = one of the speed levels (S1, S2)
                    t(i) = one of the resource trade-offs (T1, T2)
                    m(i) = one of the transmission modes (M1, M2)
          ID = data identifier
          TTL = time to live value
          DF = don't fragment flag
          Opts = the set of desired options including zero or more
                 of the following:
                    sr = source route
                    rr = return route
                    sl = security labelling
                    sid = stream identifier
                    its = internet timestamp
                    sts = satellite timestamp
          Data = data unit for delivery
          L = length of data unit
          t = time of event initiation
          N = time elapsed during transmission

                                        System Development Corporation
     1 June 1981                   -12-                        IEN 186


     3.2.5  Event List

     The events are drawn from the interaction primitives specified in
     section  3.1  above.  An event is composed of a service primitive
     and an abstract timestamp to indicate the time of  event  initia-
     tion.  The event list:

      1.  SEND( S, D, P, TOS(p(i), r(i), s(i), t(i), m(i)),  ID,  TTL,
          DF, Opts(sr, rr, sl, sid, its, sts), Data, L) at time t

      2.  NULL - Although no service request is issued by ULP, certain
          conditions  within  IP  or  lower  layers  produce a service
          response.



     3.2.6  Events and Actions

     The following section defines the set of  possible  actions  eli-
     cited by each event.


     EVENT = SEND( S, D, P, TOS(p(i), r(i), s(i), t(i), m(i)), ID, TTL, DF,
                  Opt(sr, rr, sl, sid, its, sts), Data, L ) at time t

        Actions:

            1. DELIVER Data at time t+N to protocol P at destination D
               with all of the following properties:

                   a. The time elapsed during data transmission satisfies
                      the time-to-live limit, i.e. N <= TTL.

                   b. The quality of data transmission is at least
                      equal to the relative levels specified by
                      TOS(p(i), r(i), s(i), t(i), m(i)).

                   c. if (DF = TRUE)
                      then IP fragmentation has not occurred in transit.

                   d. if (Opts contains sr)
                      then Data has visited in transit at least the nodes
                            named by source route provided in SEND.

                   e. if (Opts contains rr)
                      then the list of nodes visited in transit is
                           delivered with Data.

                   f. if (Opts contains sl)
                      then the security label is delivered with Data.

                   g. if (Opts contains sid)

                                        System Development Corporation
     1 June 1981                   -13-                        IEN 186


                      then the stream identifier is delivered with Data

                   h. if (Opts contains its)
                      then the internet timestamp is delivered with Data

                   j. if (Opts contains sts)
                      then the satellite timestamp is delivered with Data

          OR,
            2. DELIVER to protocol P at source S indicating one of
               the following error conditions:

                    a. destination D unreachable

                    b. protocol P unreachable

                    c. if (DF = TRUE)
                       then fragmentation needed but prohibited

                    d. if (Opts contains any option)
                       then parameter problem with option.

          OR,
            3. no action



      EVENT = NULL

          Actions:

            1. DELIVER to protocol P at source S indicating
               the following error condition:

                   a. error conditions in subnet layer

                                        System Development Corporation
     1 June 1981                   -14-                        IEN 186


     4.  DESCRIPTION OF LOWER LAYER SERVICE REQUIREMENTS

     This section describes the minimal services required of the  sub-
     network layer.
     The services required are:

     o transparent data transfer between hosts within a subnetwork

     o error reporting

     A description of each service follows.

     4.1  Data Transfer

     The subnetwork layer must provide  a  transparent  data  transfer
     between  hosts  within  a single subnetwork.  Only the data to be
     delivered, and the necessary control and  addressing  information
     should  be  required as input from IP.  Intranet routing and sub-
     network operation  shall  be  handled  by  the  subnetwork  layer
     itself.

     The subnetwork need not  be  a  reliable  communications  medium.
     Data  should  arrive  with non-zero probability at a destination.
     Data may not necessarily arrive in the same order as it was  sup-
     plied  to  the subnetwork layer, nor is data guaranteed to arrive
     error free.

     4.2  Error Reporting

     The subnetwork layer  shall  provide  reports  to  IP  indicating
     errors from the subnetwork and lower layers as feasible.
     The specific error requirements of the subnetwork layer have  not
     been defined.  This area needs further examination.

                                        System Development Corporation
     1 June 1981                   -15-                        IEN 186


     5.  LOWER LAYER SERVICE/INTERFACE SPECIFICATION

     This section specifies the minimal subnetwork  protocol  services
     required by IP and the interface through which those services are
     accessed.  The first part defines the interaction primitives  and
     their  parameters  for the lower interface.  The second part con-
     tains the abstract machine specification of the lower layer  ser-
     vices and interaction discipline.

     5.1  Interaction Primitives

     An interaction primitive defines  the  purpose  and  contents  of
     information  exchanged between two protocol layers.  Two kinds of
     primitives, based on  the  direction  of  information  flow,  are
     defined.   Service  requests  pass  information downward; service
     responses pass information upward.   These  primitives  need  not
     occur  in pairs, nor in a synchronous manner.  That is, a request
     does not necessarily elicit a "response"; a "response" may  occur
     independently of a request.

     The information associated with an  interaction  primitive  falls
     into   two  categories:  parameters  and  data.   The  parameters
     describe the data and indicate how the data  is  to  be  treated.
     The  data is not examined or modified.  The format of interaction
     primitive information is implementation dependent and so  is  not
     specified.

     A given IP implementation may have slightly different  interfaces
     imposed by the nature of the subnetwork or execution environment.
     Under such circumstances,  the  primitives  can  be  modified  to
     include  more  parameters or include additional primitives can be
     defined.  However, all IPs must provide at  least  the  interface
     specified below to guarantee that all IP implementations can sup-
     port the same protocol hierarchy.


     5.1.1  Service Request Primitives

     A single service request primitive is required from  the  SNP,  a
     SNP_SEND primitive.

     5.1.1.1  SNP_SEND

     The SNP_SEND contains an IP datagram, a destination, and  parame-
     ters  describing  the  desired  transmission  quality.   The  SNP
     receives in an SNP_SEND at least the following information:

     o local destination address - local subnetwork address of  desti-
      nation host or gateway

     o type of service  indicators  -  relative  transmission  quality
      associated with the datagram

                                        System Development Corporation
     1 June 1981                   -16-                        IEN 186


         - precedence - one of five levels : (P1, P2,  P3,  P4,  P5  )
                        where P1 <= P2 <= P3 <= P4 <= P5

         - reliability - one  of  four  levels  :  (R1,  R2,  R3,  R4)
                         where R1 <= R2 <= R3 <= R4

         - speed - one of two levels : (S1, S2) where S1 <= S2

         - resource trade-off  -  speed  or  reliability  :  (T1,  T2)
                                where T1 = speed, T2 = reliability

         - transmission mode - stream or datagram  :  (M1,  M2)  where
                               M1 = stream, M2 = datagram

     o length - size of the datagram

     o datagram

     5.1.2  Service Response Primitives

     One  service  request  primitive  is  required  to  support  IP's
     datagram service, the SNP_DELIVER primitive.

     5.1.2.1  SNP_DELIVER

     The SNP_DELIVER contains only a datagram which is an  independent
     entity  containing  all  the  information  needed  by  IP.  An IP
     receives in an SNP_DELIVER at least the following information:

     o datagram

     In addition, a SNP_DELIVER may contain  error  reports  from  the
     SNP,  either  together  with  a datagram or independently of one.
     This area needs further examination and definition.



     5.2  Abstract Machine Definition of Lower Level Services and
          Interaction Discipline

     The abstract state machine defines the  behavior  of  the  entire
     service  machine  with  respect  to the lower layer protocol.  An
     abstract machine definition is composed of a machine  identifier,
     a  state  diagram,  a  state vector, a set of data structures, an
     event list, and an events and actions correspondence.

     5.2.1  Machine Identifier

     Each lower interface state machine is uniquely identified by  the
     four values:

                                        System Development Corporation
     1 June 1981                   -17-                        IEN 186


     o source address

     o destination address

     o protocol

     o identification

     5.2.2  State Diagram

     The lower interface state machine has a single state which  never
     changes.  No diagram is needed.


     5.2.3  State Vector

     No state vector is needed for the lower interface state machine.


     5.2.4  State Machine Data Structures

     No data  structures  are  used  for  the  lower  interface  state
     machine.   However, the following abbreviations are used to refer
     to parameters of the interaction primitives:

          LD = local subnetwork destination address
          TOS = type of service where
                    p(i) = one of the precedence levels (P1, P2, P3, P4, P5)
                       (Note: read p(i) as "p sub i")
                    r(i) = one of the reliability levels (R1, R2, R3, R4)
                    s(i) = one of the speed levels (S1, S2)
                    t(i) = one of the resource trade-offs (T1, T2)
                    m(i) = one of the transmission modes (M1, M2)
          L = datagram length



     5.2.5  Event List

     The events are drawn from the interactions  primitives  specified
     in  section  5.1 above.  An event is composed of a service primi-
     tive with its parameters and data.

      1.  SNP_SEND(  LD,  TOS(p(i),  r(i),  s(i),  t(i),   m(i)),   L,
          Datagram)

      2.  NULL - Although IP issues no service request, certain condi-
          tions within the subnet layer elicit a service response.

                                        System Development Corporation
     1 June 1981                   -18-                        IEN 186


     5.2.6  Events and Actions

     The following section defines the set of  possible  actions  eli-
     cited by each event.

     EVENT = SNP_SEND( LD, TOS(p(i), r(i), s(i), t(i), m(i)), L, Datagram)

          ACTIONS:

               1. SNP_DELIVER Datagram to IP at local destination LD with
                  all of the following properties:

                   a. The quality of data transmission is at least
                      equal to the relative levels specified by
                      TOS(p(i), r(i), s(i), t(i), m(i)).

             OR,
               2. no action


     EVENT = NULL

          ACTIONS:

               1. SNP_DELIVER to IP indicating the following error condition:

                    a. error conditions within the subnet layer

                                        System Development Corporation
     1 June 1981                   -19-                        IEN 186


     6.  MECHANISM SPECIFICATION

     This section  defines  the  mechanisms  supporting  the  services
     offered  by  IP.    The  first  subsection motivates the specific
     mechanisms chosen and  discusses  the  underlying  philosophy  of
     those  choices.  The second subsection defines the format and use
     of the IP header fields.  The last subsection specifies the  peer
     protocol interactions with a state machine model.

     6.1  Overview of IP Mechanisms

     The IP mechanisms are motivated by the IP services, described  in
     section 2:

     o intact datagram delivery service

     o virtual network service

     o error reporting service

     Each service could be supported by any of a  set  of  mechanisms.
     The selection of mechanisms is guided by design standards includ-
     ing simplicity, generality,  flexibility,  and  efficiency.   The
     following mechanism descriptions identify the service or services
     supported, discuss the design criteria  used  in  selection,  and
     explain how the mechanisms work.

     6.1.1  Routing Mechanism

     IP contains an adaptive routing mechanism to support the delivery
     service.   The  routing  mechanism  uses  the internet addressing
     scheme and internet topology data to direct datagrams  along  the
     best path between source and destination.  The mechanism provides
     routing options for ULPs needing the  flexibility  to  select  or
     record routes and routing information.

     A distinction is made between names, addresses,  and  routes.   A
     name  indicates the object sought independently of physical loca-
     tion.  An address indicates where the object is.  A  route  indi-
     cates  how to get there. It is the task of the upper layer proto-
     cols to map from names to addresses.  The internet protocol  maps
     from  internet  addresses  to  local  subnet addresses to perform
     routing through the internet.  It is the task of lower layer pro-
     tocols  to  map from the local subnet addresses to routes through
     local subnetworks.

     Internet addresses have a fixed length of four octets (32  bits).
     An  internet  address  begins with a one octet network number and
     ends with a three octet REST field.  The REST field usually  con-
     tains a local subnetwork address.  However, alternate schemes for
     use of this field can extend the address range to allow more sub-
     networks on the internet.

                                        System Development Corporation
     1 June 1981                   -20-                        IEN 186


          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     8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ /+-+-+-+-+
         |    NETWORK    |       REST                            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ /-+-+-+-+-+


     The 24-bit REST field, assigned by each local subnetwork,  should
     allow  for  a  single  physical  host  to act as several distinct
     internet hosts.  That is, there should exist  a  mapping  between
     internet  host  addresses  and  subnetwork/host  interfaces  that
     allows several internet addresses to correspond to one interface.
     A  host  should  be  allowed  to have several physical interfaces
     (i.e. multi-homing) and to treat the datagrams  from  several  of
     them as if they were all addressed to a single host.

     To route a datagram, an IP module examines the NETWORK  field  of
     the internet address indicating the destination for the datagram.
     If the network number is the same as the IP module's  subnetwork,
     the  module uses the REST field of the internet address to derive
     the local subnet address of the destination host.  If the network
     number  doesn't  match,  the  module  determines  a  local subnet
     address of a gateway on the best path to the destination  subnet-
     work.  In turn, the gateway IP module derives the next local sub-
     net address to either a  host  or  gateway.   In  this  way,  the
     datagram is relayed through the internet to the destination host.

     In a static environment, the routing  algorithm  is  straightfor-
     ward.  However, internet topology tends to change due to hardware
     or software failure, host availability,  or  heavy  traffic  load
     conditions.  So, each host and gateway IP along the gateway route
     also uses its current knowledge  of  internet  topology  to  make
     routing decisions.

     6.1.1.1  Routing Options

     IP provides a mechanism, called source routing, to  override  the
     gateway's  independent  routing decisions.  This mechanism allows
     an upper layer protocol to influence the gateway route a datagram
     traverses.  The ULP can pass a list of internet addresses, called
     a source route, along with a datagram.  Each address on the  list
     is  an  intermediate  destination.  The source IP module uses its
     normal routing mechanism to transmit the datagram  to  the  first
     address on the list.  At that address, the first entry is removed
     from the list, and the next address becomes the datagram's desti-
     nation.   When  the last entry of the list is removed, the normal
     destination address field becomes the final destination.

     For  testing  or  diagnostic  purposes,  a  ULP  can  acquire   a
     datagram's gateway route by using a mechanism called return rout-
     ing.  The sending ULP indicates that a record of the route is  to
     be  accumulated  in  transit.   Then, as gateway IP module on the

                                        System Development Corporation
     1 June 1981                   -21-                        IEN 186


     gateway route relays the datagram, it adds  its  address  to  the
     return  list.  The destination ULP receives the original datagram
     along with the return list containing the gateway route.

     6.1.2  Fragmentation and Reassembly

     IP contains a fragmentation mechanism to break a  large  datagram
     into  smaller  datagrams.   This  is  a more general solution for
     overcoming differences between subnetwork capacity than legislat-
     ing a restrictive datagram size small enough for every subnetwork
     on the internet.  This  mechanism  can  be  overriden  using  the
     "don't  fragment"  option to prevent fragmentation.  IP also con-
     tains a reassembly mechanism which reverses the fragmentation  to
     enable delivery of intact data portions.

     When an IP module encounters a datagram that is  too  big  to  be
     transmitted  through  a  subnetwork, it applies its fragmentation
     mechanism.  First, the module divides the  data  portion  of  the
     datagram  into two or more pieces.  The data must be broken on 8-
     octet boundaries. For each  piece,  it  then  builds  a  datagram
     header  containing  the  identification,  addressing, and options
     information needed.  Fragmentation data is adjusted  in  the  new
     headers  to correspond to the data's relative position within the
     original datagram.  The result  is  a  set  of  small  datagrams,
     called  fragments,  each  carrying a portion of the data from the
     original large datagram.  Section 6.3.7.8 defines the  fragmenta-
     tion algorithm.

     Each fragment is handled independently until the  destination  IP
     module  is  reached.   The fragments may follow different gateway
     routes as internet topology and traffic conditions change.   They
     are  also  subject  to  further fragmentation if 'smaller-packet'
     subnetworks are subsequently traversed.

     Every IP module must be able to forward a datagram of  68  octets
     without  further  fragmentation.  This  size  allows for a header
     length of up to 60 octets  and  the  minimum  data  length  of  8
     octets.

     To reassemble fragments into the original datagram, an IP  module
     combines  all  those received having the same value for the iden-
     tification, source address, destination  address,  and  protocol.
     IP  allocates reassembly resources when a "first-to-arrive" frag-
     ment is recognized.  Based  on  the  fragmentation  data  in  the
     header,  the  fragment is placed in a reassembly area relative to
     its position in the original datagram.  When  all  the  fragments
     have been received, the IP module passes the data in its original
     form to the destination ULP.

     All hosts must be prepared to  accept  datagrams  of  up  to  576
     octets (whether they arrive whole or in fragments).  It is recom-
     mended that hosts only send datagrams larger than 576  octets  if

                                        System Development Corporation
     1 June 1981                   -22-                        IEN 186


     they  have  assurance  that the destination is prepared to accept
     the larger datagrams.  The number 576 is selected to allow a rea-
     sonable  amount  of  data  to  be  transmitted in addition to the
     required header information.  For example,  this  size  allows  a
     data  block  of  512  octets  plus  64  header octets to fit in a
     datagram.  The maximum internet header size is 60 octets,  and  a
     typical  internet  header  is  20  octets,  allowing a margin for
     headers of upper layer protocols.

     Because the subnetwork may be unreliable, some  fragments  making
     up  a  complete datagram can be lost.  IP uses the "time-to-live"
     data (explained in section 6.1.4 below) to set  a  timer  on  the
     reassembly  process.   If  the timer expires before all the frag-
     ments have been collected, IP discards the partially  reassembled
     datagram.

     Only the destination IP module should perform  reassembly.   This
     recommendation  is intended to reduce gateway overhead and minim-
     ize the chance of deadlock[3].  However,  reassembly  by  private
     agreement  between  gateways  is  transparent  to the rest of the
     internet and is allowed.

     A ULP can prevent its data from being broken into smaller  pieces
     during transmission.  IP provides an override mechanism to prohi-
     bit fragmentation called "Don't Fragment."  Any internet datagram
     marked  "don't  fragment"  cannot  be  fragmented by an IP module
     along the gateway route under any circumstances.  If an IP module
     cannot  deliver  such a datagram to its destination without frag-
     menting it, the module discards the datagram and returns an error
     to the source IP.  (Please note that fragmentation, transmission,
     and reassembly at the subnetwork layer is transparent to  IP  and
     can be used at any time.)

     6.1.3  Checksum

     IP assumes the subnetwork layer to be  unreliable  regardless  of
     the actual subnetwork protocol present.  So, IP provides a check-
     sum mechanism supporting the delivery service to protect  the  IP
     header from transmission errors.  The data portion is not covered
     by the IP checksum.

     An IP module recomputes the checksum each time the IP  header  is
     changed.   Changes  occur  during time-to-live reductions, option
     updates (both explained below), and fragmentation.  The  checksum
     is  currently a simple one's complement algorithm, and experimen-
     tal evidence indicates its adequacy.  However, the  algorithm  is
     provisional  and may be replaced by a CRC procedure, depending on
     future experience.

                                        System Development Corporation
     1 June 1981                   -23-                        IEN 186


     6.1.4  Time To Live

     As mentioned  in  the  routing  discussion  above,  a  datagram's
     transmission  path is subject to changes in internet topology and
     traffic conditions.  Inadvertently, a datagram might be routed on
     a  circuitous path to arrive at its destination after a consider-
     able delay.  Or, a  datagram  could  loop  through  the  same  IP
     modules  without  making  real  progress towards its destination.
     Such "old datagrams" reduce internet bandwidth and waste process-
     ing time.

     To prevent these problems, IP provides a mechanism to  limit  the
     lifetime  of  a  datagram,  called  time-to-live.  Along with the
     other sending parameters, a  ULP  specifies  a  maximum  datagram
     lifetime  in  second  units.  Each IP module on the gateway route
     decreases the time-to-live value carried in the IP header.  If an
     IP module receives an expired datagram, it discards the datagram.
     The lifetime limit is in effect  until  the  datagram's  data  is
     delivered  to  the  destination  ULP.   That is, if a datagram is
     fragmented during transmission, it can still  expire  during  the
     reassembly process.  Section 6.3.4.3 defines the reassembly algo-
     rithm use of the time-to-live data.

     6.1.5  Type of Service

     In support of the virtual network service, the  type  of  service
     mechanism allows upper layer protocols to select the transmission
     quality.  IP passes the type of service  (TOS)  command  set  for
     service  quality  to  the SNP where it is mapped into subnetwork-
     specific transmission parameters.  Not every subnetwork  supports
     all  transmission  services,  but  each  SNP on the delivery path
     should make a best effort to match the available subnet  services
     to the desired service quality.

     The TOS command set includes precedence level, reliability level,
     speed  level, resource trade-off, and transmission mode.  Several
     subnetworks offer a precedence service where treating  high  pre-
     cedence  traffic  is  processed before other traffic.  A few net-
     works offer a stream service, whereby one can achieve  low  delay
     and  constant  datagram  interarrival  time  by reserving network
     resources.  Another choice involves a low-delay vs.  high  relia-
     bility  trade-off.   Usually  subnetworks invoke more complex and
     delay producing mechanisms as the need for reliability increases.

     6.1.6  Data Options

     Motivated by the virtual network service, IP provides  a  mechan-
     ism,  called  options, to carry certain identification and timing
     data in a standard manner through the internet.  The use of  this
     mechanism  by  the ULPs is optional, as the name implies, but all
     options must be supported by each IP implementation.  No  perfor-
     mance  penalty  is exacted from other services because the option

                                        System Development Corporation
     1 June 1981                   -24-                        IEN 186


     data requires no additional processing by IP; it is simply passed
     on to the receiving ULP.

     The data options carry  three  kinds  of  information:  security,
     stream  identification, and timing.  The security data is used by
     DOD hosts needing to  transmit  security  and  TCC  (closed  user
     groups)  parameters  through  the  internet in a standard manner.
     The stream identification option provides  a  way  for  a  SATNET
     stream identifier to be carried both through stream-oriented sub-
     networks and subnets not supporting the stream concept.  The tim-
     ing  data,  useful for testing and diagnostics, includes internet
     timestamps and satellite timestamps.


     6.1.7  Error Report Datagrams

     The error reporting service motivates a mechanism to generate and
     process error information.  The error mechanism uses the datagram
     delivery service to transfer the errors between IP modules.

     An IP module encounters errors from three  sources:  ULPs,  SNPs,
     and  other  IP  modules.  Errors from the first two appear across
     IP's interfaces and are handled on the same medium.   But  errors
     from  IP  modules  are  found  in  or caused by datagrams and are
     reported to the source IP module in an "error report datagram."

     An error report datagram is composed of a minimal IP header and a
     data  portion  to  carry  error  information.   An  error  report
     datagram is distinguished from normal datagrams by  the  protocol
     field   being  equal  to  the Gateway-Gateway Protocol's identif-
     ier[13].  The error information includes a general error type, an
     error  code,  related error information, and portions of the dis-
     carded or erroneous datagram  causing  the  report.   The  errors
     reported include:

      a.  Destination Unreachable  -  A  gateway  or  host  IP  cannot
          deliver a datagram.

             - subnet unreachable - A gateway IP  cannot  determine  a
               route to the destination subnetwork.

             - host unreachable - A  gateway  IP  cannot  determine  a
               route to the destination host.

             - protocol unreachable - The IP module at the destination
               address  cannot deliver to the unknown or inactive pro-
               tocol.

             - port unreachable - The IP  module  at  the  destination
               address cannot deliver to the unknown or inactive port.

                                        System Development Corporation
     1 June 1981                   -25-                        IEN 186


             - fragmentation needed but DF set -  A  host  or  gateway
               cannot  deliver  a  datagram  because  fragmentation is
               required but is prohibited by the don't fragment flag.

      b.  Time Exceeded - A datagram has exceeded  its  allowed  life-
          time.

             - in transit - A gateway or host finds the time  to  live
               field  in the datagram header is zero.  The datagram is
               discarded.

             - during reassembly - The destination  host  cannot  com-
               plete reassembly within the time-to-live time limit due
               to missing fragments.

      c.  Parameter Problem - A gateway or  host  cannot  deliver  the
          datagram because of some problem with the header parameters.

             - Problem with an option - An option is either  not  sup-
               ported  or incorrect.  The third octet of the data por-
               tion contains the option type of the problem option.

      d.  Source Quench - A gateway has discarded a  datagram  due  to
          congestion.  This report request the source host to cut back
          the rate at which it is sending traffic to that destination.

      e.  Redirect - A gateway has received a datagram from a host  on
          an  attached  subnet, but must forward it to another gateway
          on the same subnet.  This message requests the source IP  to
          send  subsequent  datagrams with the same destination to the
          other gateway.  The address of the other gateway appears  in
          octets 4-7.

      f.  Echo - A host or gateway may use this  report  to  establish
          connectivity.

      g.  Type 0 : Echo Reply - A host or gateway responds to a previ-
          ous Echo.

                                        System Development Corporation
     1 June 1981                   -26-                        IEN 186


     6.2  Internet Protocol Header Format


     A summary of the contents of the IP header follows:


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

                                 IP Header Format


     Note that each tick mark represents one bit position.  Each field
     description  below  includes  its  name, an abbreviation, and the
     field size. Where applicable,  the  units,  the  legal  range  of
     values, and a default value appears.


     6.2.1  Version

       abbrev: VER       field size: 4 bits

     The Version field indicates the format of the  IP  header.   This
     document describes version 4.


     6.2.2  Internet Header Length

       abbrev: IHL       field size: 4 bits
       units : 4-octets  range : 5 - 15      default : 5

     Internet Header Length is the length of the IP 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.

                                        System Development Corporation
     1 June 1981                   -27-                        IEN 186


     6.2.3  Type of Service

       abbrev: TOS       field size: 8 bits

     The Type of Service field contains the IP  parameters  describing
     the quality of service desired for this datagram.


              0     1     2     3     4     5     6     7
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                 |     |           |     |     |
           |   PRECEDENCE    | STRM|RELIABILITY| S/R |SPEED|
           |                 |     |           |     |     |
           +-----+-----+-----+-----+-----+-----+-----+-----+

           Bits 0-2:  Precedence.
           Bit    3:  Stream or Datagram.
           Bits 4-5:  Reliability.
           Bit    6:  Speed over Reliability.
           Bits   7:  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
           10X-Immediate                 01-lower
           01X-Priority                  00-lowest
           00X-Routine




     6.2.4  Total Length

         abbrev: TL           field size: 16 bits
         units: octets        range : 20 - 65,535    default: 20

     Total Length is the length of the datagram, measured  in  octets,
     including header portion and the data portion of the datagram.


     6.2.5  Identification

          abbrev: ID     field size : 16 bits

     A identifying value used to associate fragments  of  a  datagram.
     This value is usually supplied by the sending ULP as an interface
     parameter.  If not, IP generates datagram  identifications  which
     are unique for each sending ULP.

                                        System Development Corporation
     1 June 1981                   -28-                        IEN 186


     6.2.6  Flags

          abbrev:  -     field size :  3 bits


     This field contains the  control  flags  "don't  fragment"  which
     prohibits  IP  fragmentation  and "more fragments" which helps to
     identify fragments.

               0   1   2
             +---+---+---+
             |   | D | M |
             | 0 | F | F |
             +---+---+---+

           Bit 0: reserved, must be zero
           Bit 1: Don't Fragment This Datagram (DF).
           Bit 2: More Fragments Flag (MF).

     6.2.7  Fragment Offset

          abbrev: FO                field size : 13 bits
          units : 8-octet groups    range : 0 - 8191    default : 0

     This field indicates the positions of this fragment's data  rela-
     tive  to  the  beginning  of  the  data  carried  in the original
     datagram.  Both a complete datagram and a first fragment has this
     field  set  to  zero.   Section 6.1.2 describes the fragmentation
     mechanism.


     6.2.8  Time to Live

          abbrev : TTL        field size : 8 bits
          units : seconds     range : 0 - 255(=4.25 mins) default : 15

     This field indicates the maximum time the datagram is allowed  to
     remain  in  the  internet.   If  the value of this field drops to
     zero, the datagram should be destroyed.  Section 6.1.4  describes
     the time-to-live mechanism.


     6.2.9  Protocol

          abbrev : PROT       field size : 8 bits

     This field indicates which ULP is to receive the data portion  of
     the  datagram.  The numbers assigned to common ULPs are specified
     in [13].

                                        System Development Corporation
     1 June 1981                   -29-                        IEN 186


     6.2.10  Header Checksum

          abbrev :  -         field size : 16 bits

     This field contains the checksum covering  the  IP  header.   The
     checksum mechanism is described in section 6.1.3.


     6.2.11  Source Address

          abbrev : source     field size : 32 bits

     This field contains the internet address of the datagram's source
     host.   The  first octet is the Source Network, and the following
     three  octets  are  the  Source  Subnetwork  Address.    Internet
     addressing is discussed in section 6.1.1.


     6.2.12  Destination Address

          abbrev : dest       field size : 32 bits

     This field contains the internet address of the datagram's desti-
     nation host.  The first octet is the Destination Network, and the
     following three octets are the  Destination  Subnetwork  Address.
     Internet addressing is discussed in section 6.1.1.


     6.2.13  Padding

          abbrev : -          field size : variable (8 to 24 bits)

     The IP header padding is used to ensure that the IP  header  ends
     on a 32-bit boundary.  The padding field is set to zero.


     6.2.14  Options

          abbrev :  -         field size : variable

     The option field is variable in length depending  on  the  number
     and  type  of  options associated with the datagram.  The options
     mechanisms are discussed in sections 6.1.1 and 6.1.6.

     Options may have two possible formats:

      a.  a single octet of option-type, or

      b.  a variable length string containing:

           1.  an option-type octet,

                                        System Development Corporation
     1 June 1981                   -30-                        IEN 186


           2.  an option-length octet - counting the option-type octet
               and  option-length  octet  as  well  as the option-data
               octets, and

           3.  the actual option-data octets.


     The option-type octet is viewed as having 3 fields:

              0   1  2  3  4  5  6  7
             +--+--+--+--+--+--+--+--+
             |CF|CLASS|   NUMBER     |
             +--+--+--+--+--+--+--+--+

          bit  0   - copy flag, if set the option is copied into
                       every fragment if fragmentation occurs.
          bits 1-2 - option class
          bits 3-7 - option number

     The option classes are:

          0 = control
          1 = internet error
          2 = debugging and measurement
          3 = reserved for future use


     The following internet options are defined:

      COPY CLASS NUMBER LENGTH DESCRIPTION
      ---- ----- ------ ------ -----------
       0     0     0      -    End of Option list:  This option occupies
                               only 1 octet; it has no length octet.
       0     0     1      -    No Operation:  This option occupies only 1
                               octet; it has no length octet.
       1     0     2      4    Security:  Used to carry Security, and user
                               group (TCC) information compatible with DOD
                               requirements.
       1     0     3     var.  Source Routing:  Used to route the datagram
                               based on information supplied by the source.
       0     0     7     var.  Return Route:  Used to record the route a
                               datagram takes.
       1     0     8      4    Stream ID:  Used to carry the stream
                               identifier.
       0     2     4      6    Internet Timestamp.
       0     2     5      6    Satellite Timestamp.

                                        System Development Corporation
     1 June 1981                   -31-                        IEN 186


     6.2.15  Specific Option Definitions

     Each option format is defined below.  "Option type" indicates the
     value  of the option-type octet, and "length" indicates the value
     of the length-octet if appropriate.

     6.2.15.1  End of Option List

          option type : 0     option length : N/A

     This one octet option marks the end of the option  list  when  it
     does  not  coincide with the four-octet boundary indicated by the
     IP header length.  This field 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  IP
     header.  This option may be introduced or deleted upon fragmenta-
     tion as needed.


     6.2.15.2  No Operation

          option type : 1     option length : N/A

     This option may be used between options, for  example,  to  align
     the  beginning of a subsequent option on a 32 bit boundary.  This
     option may be introduced or deleted upon fragmentation as needed.


     6.2.15.3  Security

          option type : 130   option length : 4

     This option provides a way for hosts to  send  security  and  TCC
     (closed user groups) parameters through subnetworks in a standard
     manner.  The format for this option is as follows:

                                        System Development Corporation
     1 June 1981                   -32-                        IEN 186


           0          1          2          3
           01234567 89012345 67890123 45678901
          +--------+--------+--------+--------+
          |Opt.Type| Length |xxxxxxSS|  TCC   |
          +--------+--------+--------+--------+

              bits 0-7   : Option Type - described above
              bits 8-15  : Length - described above
              bits 16-21 : Not Used - must be zero
              bits 22-23 : SS - security, specifies security level:
                                   11-top secret
                                   10-secret
                                   01-confidential
                                   00-unclassified

              bits 24-31 : TCC - transmission control code, provides
                                 a means to compartmentalize traffic
                                 and define controlled communities
                                 of interest among subscribers.

     (This format is subject to change according to DOD requirements.)

     6.2.15.4  Source Route

          option type : 131   option length : variable

     The source route option provides a means for the source ULP of  a
     datagram  to  supply routing information to be used by IP modules
     along the gateway route.

     The option begins with the option type code.  The second octet is
     the  option  length  which  includes  the  option type octet, the
     length octet, and the source route list.  A source route list  is
     composed  of  one  or  more  internet  addresses.   Each internet
     address is 4 octets long.  When the source route list  is  empty,
     the option is removed from the datagram and the remaining routing
     is based on the destination  address  field.   The  source  route
     option is described in section 6.1.1.


     6.2.15.5  Return Route

          option type : 7     option length : variable

     The return route option provides a way  to  record  a  datagram's
     route.

     The option begins with the option type code.  The second octet is
     the option length which includes the option type code, the length
     octet, and the return route list.  A return route  list  is  com-
     posed of a series of internet addresses.  The return route option
     is described in section 6.1.1.

                                        System Development Corporation
     1 June 1981                   -33-                        IEN 186


     6.2.15.6  Stream Identifier

          option type : 136   option length : 4

     This option provides a way for 16-bit  stream  identifier  to  be
     carried  through  the  internet for use by subnetworks supporting
     the stream concept such as the SATNET.



     6.2.15.7  Internet Timestamp

          option type : 68    option length : 10

     The internet address of the "stamper" is  followed  by  a  32-bit
     time  measured  in milliseconds.  Time zero is defined as January
     1, 1980, GMT modulo 2^32 (=49.71 days).



     6.2.15.8  Satellite Timestamp

          option type : 69         option length : 10

     The internet address of the "stamper" is  followed  by  a  32-bit
     time  measured  in milliseconds.  Time zero is defined as January
     1, 1980, GMT modulo 2^32 (=49.71 days).


     6.2.16  Error Report Datagrams

     An error report datagram informs source IPs of erroneous or  dis-
     carded  datagrams.  Such a datagram is identified by its protocol
     field being equal to the GGP  identifier[13].   An  error  report
     datagram  is  made  up  of a minimal IP header and a data portion
     carrying error information.  The first octet of the data  portion
     contains  the  error  type octet.  The next two octets hold addi-
     tional error information which depends on the  error  type.   The
     fourth  octet  is  not used.  Beginning with the fifth octet, the
     erroneous datagram's header and first 64 data octets may appear.

                                        System Development Corporation
     1 June 1981                   -34-                        IEN 186



         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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Type      |     Code        |               |   Not Used    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        \ Header + 64 data octets from erroneous or discarded datagram  \
        \                                                               \
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Error Datagram Data Portion


     The error types and related error information are defined below:

          Type   Code   Description
          ----   ----   ----------
           3      0     Destination Unreachable due to unreachable subnetwork.
           3      1     Dest. Unreachable due to unreachable host.
           3      2     Dest. Unreachable due to unreachable or unknown
                           protocol.
           3      3     Dest. Unreachable due to unreachable or inactive port.
           3      5     Dest. Unreachable due to fragmentation needed but
                           prohibited by don't fragment flag.
           11     0     Time Exceeded in transit.
           11     1     Time Exceeded during reassembly.
           12     0     Parameter Problem due to incorrect or unsupported
                           option.
            4     -     Source Quench due to congestion and discarded datagram
                           in a gateway.
            5     -     Redirect due to more direct path via alternate gateway.
                           Octets 4-7 carry the address of the alternate
                           gateway.  The redirected datagram follows at octet 8.
            8     -     Echo used to establish internet topology. No
                           erroneous datagram carried in data portion.
            0     -     Echo Reply responds to previous echo. No erroneous
                           datagram carried in data portion.

                                        System Development Corporation
     1 June 1981                   -35-                        IEN 186


     6.3  Extended State Machine Representation

     The IP protocol mechanism is defined by a state machine represen-
     tation  made up of a set of states,  a set of transitions between
     states, and a set of input events causing the state  transitions.
     In  addition,  a  state machine has an initial state whose values
     are assumed at state machine instantiation.

     6.3.1  State Machine Identification

     Each datagram is  an  independent  unit.   Therefore,  one  state
     machine  instance  exists  for  each  datagram.  Each datagram is
     uniquely named by the four values:

        o+ source address

        o+ destination address

        o+ protocol

        o+ identification

     6.3.2  State Machine Diagram

     The following diagram depicts a simplified IP state machine.

                                        System Development Corporation
     1 June 1981                   -36-                        IEN 186




                          send or receive a complete datagram
                                  __
                                 |  |
                                 |  v
                      *  *  *  *  *  *
                    *                  *
                   *      INACTIVE      *
                    *                  *
                      *  *  *  *  *  *
                       |           ^
              receive  |           |receive complete datagram,
               fragment|           | or final fragment,
                       |           |  or reassembly timeout
                       v           |
                      *  *  *  *  *  *
                    *                  *
                   *    REASSEMBLING    *
                    *                  *
                      *  *  *  *  *  *
                     |  ^
                     |__|
               receive
               fragments





     6.3.3  State Vector

     A state vector consists of the following elements :

        o+ STATE NAME = (inactive, reassembling)

        o+ REASSEMBLY  RESOURCES  =  control  information  and  storage
          needed  to  reassemble fragments into the original datagram,
          including:

             - reassembly map : a representation of each 8-octet  unit
               of  data  and its relative location within the original
               datagram.

             - timer : value of the reassembly timer in  unit  seconds
               ranging from 0 to 255.

             - total data  length  :  size  of  the  data  carried  in
               datagram being reassembled.

             - header : storage area for the  header  portion  of  the
               datagram being reassembled.

                                        System Development Corporation
     1 June 1981                   -37-                        IEN 186


             - data :  storage  area  for  the  data  portion  of  the
               datagram being reassembled.
     A state machine's initial state is inactive with unused  reassem-
     bly resources.


     6.3.4  State Machine Data Structures

     The IP state machine references certain data areas  corresponding
     to  the  state  vector,  and  each  interaction primitive : SEND,
     DELIVER, SNP_SEND, and SNP_DELIVER.  For clarity  in  the  events
     and  actions  section,  data  structures  are declared in Ada for
     these data areas.  However, a data  structure  may  be  partially
     typed  or completely untyped where specific formats or data types
     are implementation dependent.

     6.3.4.1  state_vector

     The definition of an IP state vector appears section 6.3.1 above.
     A state_vector structure is declared as:

          type state_vector_type is
            record
              state_name : (INACTIVE, REASSEMBLING);
              reassembly_map
              timer
              total_data_length
              header
              data
            end record;


     6.3.4.2  from_ULP

     The from_ULP structure holds the interface  parameters  and  data
     associated  with  the  SEND  primitive,  as  specified in section
     3.1.1.  The from_ULP structure is declared as:

          type from_ULP_type is
            record
              source_addr
              destination_addr
              protocol
              type_of_service
              identifier
              time_to_live
              dont_fragment
              length
              data
              options
            end record;

                                        System Development Corporation
     1 June 1981                   -38-                        IEN 186


     6.3.4.3  to_ULP

     The to_ULP structure holds interface parameters and data  associ-
     ated  with  the DELIVER primitive, as specified in section 3.1.2.
     The to_ULP structure is declared as:

          type to_ULP_type is
            record
              source_addr
              destination_addr
              protocol
              type_of_service
              length
              data
              options
              error
            end record;


     6.3.4.4  from_SNP

     The  from_SNP  structure  holds  the  interface  parameters   and
     datagram  associated with the SNP_DELIVER primitive, as specified
     in section 5.2.2.  The from_SNP structure is declared as:

          type from_SNP_type is
            record
               local_destination_addr
               dtgm: datagram_type;
               error
            end record;

     The dtgm element is itself a structure as specified below.

     6.3.4.5  to_SNP

     The to_SNP structure holds the  data  and  parameters  associated
     with  the  SNP_SEND  primitive  specified  in section 5.2.1.  The
     to_SNP structure is declared as:

          type to_SNP_type is
            record
              local_destination_addr
              type_of_service_indicators
              length
              dtgm: datagram_type;
            end record;

     The dtgm element  is  itself  a  structure  as  specified  below.
     specified below.

                                        System Development Corporation
     1 June 1981                   -39-                        IEN 186


     6.3.4.6  dtgm

     A dtgm structure holds a datagram made up of a header portion and
     a  data portion as specified in section 6.2.  A dtgm structure is
     declared as:

          type datagram_type is
             record
               version : HALF_OCTET;
               header_length : HALF_OCTET;
               type_of_service : OCTET;
               total_length : TWO_OCTETS;
               identification : TWO_OCTETS;
               dont_frag_flag : BOOLEAN;
               more_frag_flag : BOOLEAN;
               fragment_offset : ONE_N_FIVE_EIGHTHS_OCTETS;
               time_to_live : OCTET;
               protocol : OCTET;
               header_checksum : TWO_OCTETS;
               source_addr : FOUR_OCTETS;
               destination_addr : FOUR_OCTETS;
               options : option_type;
               data : array(1..DATA_LENGTH) of INTEGER;
            end record;

          subtype HALF_OCTET is INTEGER range 0..15;
          subtype OCTET is INTEGER range 0..255;
          subtype ONE_N_FIVE_EIGHTHS_OCTETS is INTEGER range 0..8191;
          subtype TWO_OCTETS is INTEGER range 0..65535;
          subtype FOUR_OCTETS is INTEGER range 0..4294967296;


     6.3.5  Event List

     The following list defines the set of possible events  in  an  IP
     state machine:

      a.  SEND from ULP - A ULP passes interface parameters  and  data
          to IP for delivery across the internet.

      b.  SNP_DELIVER from SNP - SNP passes to IP a datagram  received
          from subnetwork protocol.

      c.  TIMEOUT - The timing mechanism  provided  by  the  execution
          environment  indicates  a previously specified time interval
          has elapsed.


     6.3.6  State Machine Events and Actions

     This section is organized in three parts.  The  first  part  con-
     tains a decision table representation of state machine events and

                                        System Development Corporation
     1 June 1981                   -40-                        IEN 186


     actions.  The decision tables are organized by state; each  table
     corresponds to one event.

     The second part specifies the decision functions appearing at the
     top  of each column of a decision table.  These functions examine
     attributes of the event and the state vector to return a  set  of
     decision  results.   The  results  become  the  elements  of each
     column.  A "--" element represents a "don't care" condition where
     a decision result does not determine the action procedure chosen.

     The third section specifies action procedures  appearing  at  the
     right  of every row.  Each row of the decision table combines the
     decision  results  to  determine  appropriate  event  processing.
     These procedures specify event processing algorithms in detail.

     6.3.6.1  Events and Actions Decision Tables

     STATE = INACTIVE
     ================

     EVENT = SEND from ULP


     =============================
     | ULP  |where | need | can  |
     |params|  to  |  to  | frag |
     |valid |      | frag |      |
     =============================
     | NO   |  --  |  --  |  --  |error to ULP(PARAM_PROBLEM)
     ---------------------------------------------------------
     | YES  |  ULP |  --  |  --  |local delivery
     ---------------------------------------------------------
     | YES  |  IP  |  --  |  --  | **illegal
     ---------------------------------------------------------
     | YES  |REMOTE|  NO  |  --  |build&send
     ---------------------------------------------------------
     | YES  |REMOTE|  YES |  NO  |error to ULP(CAN'T FRAGMENT)
     ---------------------------------------------------------
     | YES  |REMOTE|  YES | YES  |fragment&send
     ---------------------------------------------------------

     Comments:
        A ULP passes data to IP for internet delivery. IP validates the
        interface parameters, determines the destination, and dispatches
        the ULP data to its destination.

                                        System Development Corporation
     1 June 1981                   -41-                        IEN 186


     STATE = INACTIVE
     ================

     EVENT = DELIVER from SNP

     ====================================
     |check-| SNP  | TTL  |where |  a   |
     |  sum |params|valid | to   | frag |
     |valid |valid |      |      |      |
     ====================================
     |  NO  |  --  |  --  |  --  |  --  |discard
     ------------------------------------------------------------------
     |  YES |  NO  |  --  |  --  |  --  |error to source(PARAM_PROBLEM)
     ------------------------------------------------------------------
     |  YES |  YES |  NO  |  --  |  --  |error to source(EXPIRED_TTL)
     ------------------------------------------------------------------
     |  YES |  YES |  YES | ULP  |  NO  |remote delivery
     ------------------------------------------------------------------
     |  YES |  YES |  YES | ULP  |  YES |reassemble;STATE:=REASSEMBLING
     ------------------------------------------------------------------
     |  YES |  YES |  YES |  IP  |  NO  |analyze
     ------------------------------------------------------------------
     |  YES |  YES |  YES |  IP  |  YES |reassemble;STATE:=REASSEMBLING
     ------------------------------------------------------------------
     |  YES |  YES |  YES |REMOTE|  --  |error to source(HOST_UNREACH)
     ------------------------------------------------------------------

     Comments:
       The SNP has delivered datagram from another IP.  IP validates the
       datagram header, and either delivers the data from a complete
       datagram to its destination within the host or begins reassembly
       for a datagram fragment.

                                        System Development Corporation
     1 June 1981                   -42-                        IEN 186



     STATE = REASSEMBLING
     ====================

     EVENT = DELIVER from SNP

     ===========================================
     |check-| SNP  | TTL  |where |  a   |reass.|
     |  sum |params|valid |  to  | frag | done |
     |valid |valid |      |      |      |      |
     ===========================================
     |  NO  |  --  |  --  |  --  |  --  |  --  |discard
     --------------------------------------------------------------------------
     |  YES |  NO  |  --  |  --  |  --  |  --  |error to source(PARAM_PROBLEM)
     --------------------------------------------------------------------------
     |  YES |  YES |  NO  |  --  |  --  |  --  |error to source(EXPIRED_TTL)
     --------------------------------------------------------------------------
     |  YES |  YES |  YES | ULP  |  NO  |  --  |remote delivery;state:=INACTIVE
     --------------------------------------------------------------------------
     |  YES |  YES |  YES | ULP  |  YES |  NO  |reassemble
     --------------------------------------------------------------------------
     |  YES |  YES |  YES | ULP  |  YES |  YES |reass delivery;state:=INACTIVE
     --------------------------------------------------------------------------
     |  YES |  YES |  YES |  IP  |  NO  |  --  |analyze;state:=INACTIVE
     --------------------------------------------------------------------------
     |  YES |  YES |  YES |  IP  |  YES |  NO  |reassemble
     --------------------------------------------------------------------------
     |  YES |  YES |  YES |  IP  |  YES |  YES |analyze;state:=INACTIVE
     --------------------------------------------------------------------------
     |  YES |  YES |  YES |REMOTE|  --  |  --  |error to source(HOST_UNREACH)
     --------------------------------------------------------------------------

     Comment:
       The SNP has delivered a datagram associated to an earlier received datagram
       fragment.  IP validates the header and either continues the reassembly
       process with the datagram fragment or delivers the data from the completed
       datagram to its destination within the host.




     EVENT = TIMEOUT

       reassembly timeout; state:=INACTIVE
       -----------------------------------

     Comment:
       The time-to-live period of the datagram being reassembled has elapsed.
       The incomplete datagram is discarded; the source IP is informed.

                                        System Development Corporation
     1 June 1981                   -43-                        IEN 186


     6.3.6.2  Decision Functions

     The following functions examine information contained  in  inter-
     face  parameters,  interface  data,  and the state vector to make
     decisions.  These decisions can be thought of as further  refine-
     ments  of  the  event  and/or state.  The functions return values
     represent the possible decisions.


     6.3.6.2.1  checksum valid

     The  checksum_valid  function  examines  an  incoming  datagram's
     header to determine whether it is free from transmission errors.

     The data effects of this function are:

        - Data examined only:

               from_SNP.dtgm.version              from_SNP.dtgm.fragment_offset
               from_SNP.dtgm.header_length        from_SNP.dtgm.time_to_live
               from_SNP.dtgm.type_of_service      from_SNP.dtgm.protocol
               from_SNP.dtgm.total_length         from_SNP.dtgm.source_addr
               from_SNP.dtgm.identification       from_SNP.dtgm.destination_addr
               from_SNP.dtgm.dont_frag_flag       from_SNP.dtgm.options
               from_SNP.dtgm.more_frag_flag       from_SNP.dtgm.padding

        - Return values:

               NO   -- checksum did not check indicating header fields
                         contain errors
               YES  -- checksum was consistent

     The algorithm:

        --The checksum algorithm is the 16-bit one's complement
        --of the one's complement sum of all 16-bit words in
        --the IP header.  For purposes of computing the checksum,
        --the checksum field is set to zero.

            --implementation dependent action

                                        System Development Corporation
     1 June 1981                   -44-                        IEN 186


     6.3.6.2.2  ULP_params_valid

     The ULP_params_valid function examines the  interface  parameters
     received  from a ULP to see if all values are within legal ranges
     and desired options are supported.

     The data effects of this function are:

        - Data examined only:

               from_ULP.time_to_live
               from_ULP.options


        - Return values:

               NO - some value is  illegal or a desired option is not supported.

               YES - examine values are within legal ranges and desired
                     options can be supported.
     The algorithm:

          if (
               --The time-to-live value must be greater than zero to
               --allow IP to transmit it at least once.
               (from_ULP.time_to_live < 0 )

            or --The options requested should be checked for consistency.
               --implementation dependent action

            or --Check other implementation dependent values.
              )

          then return NO

          else return YES;

          end if;

                                        System Development Corporation
     1 June 1981                   -45-                        IEN 186


     6.3.6.2.3  SNP_params_valid

     The SNP_params_valid function examines the  interface  parameters
     and  the  datagram received from the local subnetwork protocol to
     see if all values are within legal  ranges  and  no  errors  have
     occured.

     The data effects of this function are:

        - Data examined only:

               from_SNP.dtgm.version         from_SNP.dtgm.source_addr
               from_SNP.dtgm.header_length   from_SNP.dtgm.destination_addr
               from_SNP.dtgm.total_length    from_SNP.dtgm.options
               from_SNP.dtgm.protocol        other information/errors from SNP

        - Return values:

               NO - some value or values are illegal or an error has occured

               YES - examined values are within legal ranges and no
                     errors have occured

     The algorithm:

      if (  --The current IP header version number is 4.
          (from_SNP.dtgm.version /= 4)

            --The minimal IP header is 5 32-bit units in length.
        or (from_SNP.dtgm.header_length < 5)

            --The smallest legal datagram contains only a header and is
            --20 octets in length.
        or (from_SNP.dtgm.total_length < 20)

            --The legal protocol identifiers are provided in [13].
        or (from_SNP.dtgm.protocol is not one of the acceptable identifiers)

            --The legal network address mappings are provided in [12].
        or (from_SNP.dtgm.source_addr is not an acceptable address)

            --The legal network address mappings are provided in [12].
        or (from_SNP.dtgm.destination_addr is not an acceptable address)
           )

       then return NO

       elseif (any implementation dependent values received from the
                SNP are illegal or indicate error conditions)
           then return NO
           else return YES;   --Otherwise, all values look good.
           endif;

                                        System Development Corporation
     1 June 1981                   -46-                        IEN 186


       endif;

                                        System Development Corporation
     1 June 1981                   -47-                        IEN 186


     6.3.6.2.4  where to

     The where_to function determines the destination of the  incoming
     datagram  by  examining  the address fields and options fields of
     the datagram header.

     The data effects of this function are:

        - Data examined only:

               from_SNP.dtgm.destination_addr
               from_SNP.dtgm.protocol
               from_SNP.dtgm.options

        - Return values:

               ULP - destination is an upper layer protocol at this location
               IP  - destination is this IP module
               REMOTE - destination is some remote location

     The algorithm:

        --The source route influences the datagram's gateway route.

          if ((from_SNP.dtgm.options contains the source routing option)
          then return REMOTE;
          endif;

        --Examine the destination address field of the datagram header.

          if ((from_SNP.dtgm.destination_addr /= this site's address)
          then
              --It's destined for another site.
               return REMOTE
          else
              --It's destined for this site.
               if (from_SNP.dtgm.protocol = the IP identifier)
               then return IP
               else
                   --Verify existence of addressed ULP at this location.
                    if (from_SNP.dtgm.protocol exists here)
                    then return ULP
                    end if;
               end if;
          end if;

                                        System Development Corporation
     1 June 1981                   -48-                        IEN 186


     6.3.6.2.5  TTL valid

     The TTL_valid function examines the IP header time-to-live  field
     of  an  incoming  datagram  to determine whether the datagram has
     exceeded its allowed lifetime.

     The data effects of this function are:

        - Data examined only:

               from_SNP.dtgm.time_to_live

        - Return values:

               NO - the datagram has expired
               YES - the datagram has some life left in it

     The algorithm:

         --Decrement from_SNP.dtgm.time_to_live field by the maximum
         --of either the amount of time elapsed since the last IP module
         --handled this datagram (if known) or one second.

          if (( from_SNP.dtgm.time_to_live
                 - maximum(number of seconds elapsed since last IP, 1))
               <= 0 )
          then return NO
          else return YES;

                                        System Development Corporation
     1 June 1981                   -49-                        IEN 186


     6.3.6.2.6  a frag

     The a_frag  function  examines  certain  fields  in  an  incoming
     datagram's header to determine whether the datagram is a fragment
     of a larger datagram.

     The data effects of this algorithm are:

        - Data examined only:

               from_SNP.dtgm.fragment_offset
               from_SNP.dtgm.more_frag_flag

        - Return values:

               NO - the datagram has not been fragmented
               YES - the datagram is a part of a larger datagram

     The algorithm:

        if ((from_SNP.dtgm.fragment_offset = 0)     --contains the beginning
            and (from_SNP.dtgm.more_frag_flag = 0)) --and the end of the data

       then return NO   --therefore it is an unfragmented datagram

       else return YES; --otherwise it contains only a portion of the data
                        --and is a fragment.

                                        System Development Corporation
     1 June 1981                   -50-                        IEN 186


     6.3.6.2.7  reassembly done

     The reassembly_done function examines the incoming  datagram  and
     the  reassembly resources to determine whether the final fragment
     has arrived to complete the datagram being reassembled.

     The data effects of this function are:
          Data examined only:

               state_vector.reassembly_map        from_SNP.dtgm.more_frag_flag
               state_vector.total_length          from_SNP.dtgm.header_length
               from_SNP.dtgm.fragment_offset      from_SNP.dtgm.total_length

        - Return values:

               NO - more fragments are needed to complete reassembly
               YES - this is the only fragment needed to complete reassembly

     The algorithm:

       --The total data length of the original datagram, as computed from
       --"tail" fragment, must be known before completion is possible.

         if (state_vector.total_data_length = 0)
         then
           --Check incoming datagram for "tail."

             if (from_SNP.dtgm.more_frag_flag = FALSE)
             then
               --Compute total data length and see if data in
               --this fragment fills out reassembly map.

                 if (reassembly map from 0 to
                      (((from_SNP.dtgm.total_length -          --total data
                         (from_SNP.dtgm.header_length*4)+7)/8) --  length
                      +7)/8  is set )
                 then return YES;
                 end if;
             else
               --Reassembly cannot be complete if total data length unknown.
                  return NO;
             end if;

          else --Total data length is already known.  See if data
               --in this fragment fills out reassembly map.

               if ( all reassembly map from 0 to
                       (state_vector.total_data_length+7)/8 is set)
               then return YES;  --final fragment
               else return NO;   --more to come
               end if;
          end if;

                                        System Development Corporation
     1 June 1981                   -51-                        IEN 186


     6.3.6.2.8  need to frag

     The need_to_frag function examines the interface  parameters  and
     data  from a ULP to determine whether the data can be transmitted
     as a single datagram or  must  be  transmitted  as  two  or  more
     datagram fragments.

     The data effects of this function are:

        - Data examined only:

               from_ULP.length
               from_ULP.options

        - Return values:

               NO - one datagram is small enough for the subnetwork
               YES - datagram fragments are needed to carry the data

     The algorithm:
         --Compute the datagram's length based on the length of data,
         --the length of options, and the standard datagram header size.

          if (( from_ULP.length + (number of bytes of option data) + 20 )
                  > maximum transmission unit of the local subnetwork )
          then return YES
          else return NO;
          end if;


     6.3.6.2.9  can frag

     The can_frag function examines the don't  fragment  flag  of  the
     interface parameters allows fragmentation.

     The data effects of this function are:

        - Data examined only:

               from_ULP.dont_fragment

        - Return values:

               NO - don't fragment flag is set preventing fragmentation
               YES -don't fragment flag is NOT set to allow fragmentation

     The algorithm:

          if (from_ULP.dont_fragment = TRUE)
          then return NO
          else return YES
          end if;

                                        System Development Corporation
     1 June 1981                   -52-                        IEN 186


     6.3.6.3  Decision Table Actions

     6.3.6.3.1  compute_checksum

     The compute_checksum procedure calculates a checksum value for  a
     datagram  header so that transmission errors can be detected by a
     destination IP.

     The data effects of this procedure are:

        - Data examined:
               to_SNP.dtgm.version                to_SNP.dtgm.fragment_offset
               to_SNP.dtgm.header_length          to_SNP.dtgm.time_to_live
               to_SNP.dtgm.type_of_service        to_SNP.dtgm.protocol
               to_SNP.dtgm.total_length           to_SNP.dtgm.source_addr
               to_SNP.dtgm.identification         to_SNP.dtgm.destination_addr
               to_SNP.dtgm.dont_frag_flag         to_SNP.dtgm.options
               to_SNP.dtgm.more_frag_flag         to_SNP.dtgm.padding


        - Data modified:

               to_SNP.dtgm.checksum

     The procedure:

         --The checksum algorithm is the 16-bit one's complement of
         --the one's complement sum of all 16-bit words
         --in the IP header.  For purposes of computing the checksum,
         --the checksum field is set to zero.

               --implementation dependent action

                                        System Development Corporation
     1 June 1981                   -53-                        IEN 186


     6.3.6.3.2  reassemble

     The reassemble procedure reconstructs an original  datagram  from
     datagram fragments.  The data effects of this procedure are:

        - Data examined:

               from_SNP.dtgm

        - Data modified:

               state_vector.reassembly_map             state_vector.header
               state_vector.timer                      state_vector.data
               state_vector.total_data_length

     The procedure:
       --A local variable is introduced to make the computations more clear.
       --data_in_frag equals the number of octets of data in received fragment.

        data_in_frag := (from_SNP.dtgm.total_length
                                           -from_SNP.dtgm.header_length*4);
       --Put data in its relative position in the data area of the state vector.

         state_vector.data[from_SNP.dtgm.fragment_offset*8..
                           from_SNP.dtgm.fragment_offset*8+data_in_frag] :=
                                        from_SNP.dtgm.data[0..data_in_frag-1];

       --Fill in the corresponding entries of the reassembly map representing
       --each 8-octet unit of received data.

         for j in (from_SNP.dtgm.fragment_offset)..
                  (from_SNP.dtgm.fragment_offset + data_in_frag + 7)/8) loop

           state_vector.reassembly_map[j] := 1;
         end loop;

       --Compute the total datagram length from the "tail-end" fragment.

         if (from_SNP.dtgm.more_frag_flag = FALSE)
         then state_vector.header.total_data_length :=
                                from_SNP.dtgm.fragment_offset*8 + data_in_frag;
         end if;

       --Record the header of the "head-end" fragment.

         if (from_SNP.dtgm.fragment_offset = 0)
         then state_vector.header := from_SNP.dtgm;
         end if;

       --Reset the reassembly timer if its current value is less than the
       --time-to-live field of the received datagram.

                                        System Development Corporation
     1 June 1981                   -54-                        IEN 186


         state_vector.timer := maximum(
                          from_SNP.dtgm.time_to_live, state_vector.timer);


     A reassembly algorithm may vary according to implementation  con-
     cerns, but each one must meet these  requirements:

      1.  Every destination  IP  module  must  have  the  capacity  to
          receive a datagram 576 octets in length, either in one piece
          or in fragments to be reassembled.

      2.  The      header       of       the       fragment       with
          from_SNP.dtgm.fragment_offset   equal   to  zero  (i.e.  the
          "head-end" fragment) becomes the header of the  reassembling
          datagram.

      3.  The total length of the reassembling datagram is  calculated
          from the fragment with from_SNP.dtgm.more_frag_flag equal to
          zero (i.e. the "tail-end" fragment).

      4.  A reassembly timer is associated with  each  datagram  being
          reassembled.   The  current  recommendation  for the initial
          timer setting is 15 seconds.  Note that the choice  of  this
          parameter  value is related to the buffer capacity available
          and the data rate of the subnetwork. That is, data rate mul-
          tiplied   by   timer   value   equals   reassembly  capacity
          (e.g.10Kb/s X 15secs = 150Kb).

      5.  As each fragment arrives, the reassembly timer is  reset  to
          the  maximum  of state_vector.reassembly_resources.timer and
          from_SNP.dtgm.time_to_live in the incoming fragment.

      6.  If the reassembly timer expires, the datagram being reassem-
          bled  is  discarded.  Also, an error datagram is returned to
          the source IP to report the "time exceeded  during  reassem-
          bly" error.

                                        System Development Corporation
     1 June 1981                   -55-                        IEN 186


     6.3.6.3.3  build&send

     The build&send procedure  builds  an  outbound  datagram  in  the
     to_SNP  structure  from  the  interface  parameters  and  data in
     from_ULP and passes it to the SNP  for  transmission  across  the
     subnet.

     The data effects of this procedure are:

        - Data examined:

               from_ULP.source_addr               from_ULP.time_to_live
               from_ULP.destination_addr          from_ULP.dont_fragment
               from_ULP.protocol                  from_ULP.options
               from_ULP.type_of_service           from_ULP.length
               from_ULP.identifier                from_ULP.data

        - Data modified:

               to_SNP.dtgm         to_SNP.type_of_service_indicator
               to_SNP.length       to_SNP.local_destination_addr

     The algorithm:

      --Fill in each IP header field with information from from_ULP or
      --standard values.

          to_SNP.dtgm.version := 4;     --Current IP version is 4.
          to_SNP.dtgm.type_of_service := from_ULP.type_of_service;
          --If ID is not given by ULP, the IP must supply its own.
          to_SNP.dtgm.identification := from_ULP.identifier;

          to_SNP.dtgm.dont_frag_flag := from_ULP.dont_fragment;
          to_SNP.dtgm.more_frags_flag := 0;
          to_SNP.dtgm.fragment_offset := 0;
          to_SNP.dtgm.time_to_live := from_ULP.time_to_live;
          to_SNP.dtgm.protocol := from_ULP.protocol;
          to_SNP.dtgm.source_addr := from_ULP.source_address;
          to_SNP.dtgm.destination_addr := from_ULP.destination_address;
          to_SNP.dtgm.options := from_ULP.options;
          to_SNP.dtgm.padding := (as needed to end the IP header
                                   four octet boundary);
          to_SNP.dtgm.header_length := 5 + (number of bytes of option data)/4;
          to_SNP.dtgm.total_length := (to_SNP.dtgm.header_length)*4
                                                        + (from_ULP.length);

      --Call compute_checksum to to compute and set the checksum.

          compute_checksum;

      --And, fill in the data portion of the datagram.

                                        System Development Corporation
     1 June 1981                   -56-                        IEN 186


          to_SNP.dtgm.data[0..from_ULP.length -1]  := from_ULP.data[0..
                                                        from_ULP.length-1];
      --Set the type of service and length fields for the SNP.

          to_SNP.type_of_service_indicator := to_SNP.dtgm.type_of_service;
          to_SNP.length := to_SNP.dtgm.total_length;

      --Call the route procedure to determine a local destination
      --from the internet destination address supplied by the ULP.

          route;

      --Request the execution environment to pass the contents of to_SNP
      --to the local subnetwork protocol for transmission.

          TRANSFER to_SNP to the SNP.

     NOTE: The format of the from_ULP elements is unspecified allowing an
           implementor to assign data types for the interface parameters.
           If those data types differ from the IP header types,
           the assignment statements above become type conversions.

                                        System Development Corporation
     1 June 1981                   -57-                        IEN 186


     6.3.6.3.4  route

     The route procedure examines the destination address and  options
     fields  of  an  outbound  datagram in to_SNP to determine a local
     destination address.

     The data effects of this procedure are:

        - Data examined:

               to_SNP.dtgm.destination_addr
               to_SNP.dtgm.options

        - Data modified:

               to_SNP.local_destination_addr

     The procedure:

       --The source routing option influences the path of the datagram.
       --If that option is present, use the top of the source route list
       --as the destination; otherwise use the header's destination
       --address field.

         if (source routing present in options)
         then destination := (first address on source route list)
         else destination := to_SNP.dtgm.destination_addr;
         endif;

         if (the network id field of destination matches the network id
                of the local subnet protocol )
         then
              --Translate the REST field of destination into the subnetwork
              --address of the destination on this subnet.
                 --implementation dependent action
         else
              --Find the appropriate gateway and its subnetwork address
              --based on the network id field of the destination.
                 --implementation dependent action
         end if;

       --Set the local destination interface parameter.

          to_SNP.local_destination_addr := (subnetwork address found above);

                                        System Development Corporation
     1 June 1981                   -58-                        IEN 186


     6.3.6.3.5  local delivery

     The local_delivery procedure moves the interface  parameters  and
     data  in  the  from_ULP  structure  to  the  to_ULP structure and
     delivers it to an in-host ULP.

     The data effects of this procedure are:

        - Data examined:

               from_ULP.destination_addr          from_ULP.length
               from_ULP.source_addr               from_ULP.data
               from_ULP.protocol                  from_ULP.options
               from_ULP.type_of_service

        - Data modified:

               to_ULP.source_addr                 to_ULP.length
               to_ULP.destination_addr            to_ULP.data
               to_ULP.protocol                    to_ULP.options
               to_ULP.type_of_service

     The procedure:

       --Move the interface parameters and data from the input
       --structure, from_ULP, directly to the output structure, to_ULP,
       --for delivery to a local ULP.

          from_ULP.destination_addr := to_ULP.destination_addr;
          from_ULP.source_addr      := to_ULP.source_addr;
          from_ULP.protocol         := to_ULP.protocol;
          from_ULP.type_of_service  := to_ULP.type_of_service;
          from_ULP.length           := to_ULP.length;
          from_ULP.data             := to_ULP.data;
          from_ULP.options          := to_ULP.options;

      --Request the execution environment to pass the contents of to_SNP
      --to the local subnet protocol for transmission.

          TRANSFER to_ULP to to_ULP.protocol.

                                        System Development Corporation
     1 June 1981                   -59-                        IEN 186


     6.3.6.3.6  remote delivery

     The remote_delivery procedure decomposes a datagram arriving from
     a  remote IP into interface parameters and data and delivers them
     to the destination ULP.

     The data effects of this procedure are:

        - Data examined:

               from_SNP.dtgm.source_addr          from_SNP.dtgm.total_length
               from_SNP.dtgm.destination_addr     from_SNP.dtgm.header_length
               from_SNP.dtgm.protocol             from_SNP.dtgm.data
               from_SNP.dtgm.type_of_service      from_SNP.dtgm.options

        - Data modified:

               to_ULP.destination_addr       to_ULP.length
               to_ULP.source_addr            to_ULP.data
               to_ULP.protocol               to_ULP.options
               to_ULP.type_of_service

     The algorithm:

          to_ULP.destination_addr  :=  from_SNP.dtgm.destination_addr;
          to_ULP.source_addr       :=  from_SNP.dtgm.source_addr;
          to_ULP.protocol          :=  from_SNP.dtgm.protocol;
          to_ULP.type_of_service   :=  from_SNP.dtgm.type_of_service;
          to_ULP.length            :=  from_SNP.dtgm.total_length -
                                          from_SNP.dtgm.header_length*4;
          to_ULP.data              :=  from_SNP.dtgm.data;
          to_ULP.options           :=  from_SNP.dtgm.options;

     NOTE: The format of the to_ULP elements is unspecified allowing an
           implementor to assign data types for the interface parameters.
           If those data types differ from the IP header types,
           the assignment statements above become type conversions.

                                        System Development Corporation
     1 June 1981                   -60-                        IEN 186


     6.3.6.3.7  reassembled delivery

     The reassembled_delivery procedure decomposes the  datagram  that
     has  been  reassembled in the state vector into interface parame-
     ters and data, then delivers them to a ULP.

     The data effects of this procedure are:

        - Data examined:

               state_vector.header.destination_addr
               state_vector.header.source_addr
               state_vector.header.protocol
               state_vector.header.type_of_service
               state_vector.header.header_length
               state_vector.header.total_length
               state_vector.header.options
               state_vector.data

        - Data modified:

               to_ULP.destination_addr       to_ULP.length
               to_ULP.source_addr            to_ULP.data
               to_ULP.protocol               to_ULP.options
               to_ULP.type_of_service

     The procedure:

          to_ULP.destination_addr  := state_vector.header.destination_addr;
          to_ULP.source_addr       := state_vector.header.source_addr;
          to_ULP.protocol          := state_vector.header.protocol;
          to_ULP.type_of_service   := state_vector.header.type_of_service;
          to_ULP.length            := state_vector.header.total_length;
                                       - state_vector.header.header_length*4;
          to_ULP.options           := state_vector.header.options;
          to_ULP.data              := state_vector.data;

                                        System Development Corporation
     1 June 1981                   -61-                        IEN 186


     6.3.6.3.8  fragment&send

     The fragment&send procedure breaks data that is  too  big  to  be
     transmitted  through  the  subnetwork  as  a single datagram into
     smaller pieces for transmission in several datagrams.

     The data effects of the procedure are:

        - Data examined only:

               from_ULP.source_addr               from_ULP.length
               from_ULP.destination_addr          from_ULP.data
               from_ULP.protocol                  from_ULP.options
               from_ULP.type_of_service

        - Data modified:

               to_SNP.dtgm         to_SNP.type_of_service_indicators
               to_SNP.length       to_SNP.local_destination_address

     Some "local variables" are used to make the procedure clearer:

          number_of_fragments -- number of small datagrams created from
                                 user data

          data_per_fragment -- the number of octets in each small datagram

          number_frag_blocks -- the number of 8-octet blocks in each small
                                datagram
          data_in_last_frag -- the number of octets in the last datagram

     The procedure:

       --Compute the fragmentation variables.

       --The amount of data per fragment equals the max datagram size less
       --the length of the datagram header.
          data_per_fragment   := maximum subnet transmission unit
                                  - (20 + number of bytes of option data);

          number_frag_blocks  := data_per_fragment/8;

          number_of_fragments := (from_ULP.length + (data_per_fragment-1))
                                  / data_per_fragment;

          data_in_last_frag := from_ULP.length modulo data_per_fragment;

       --Create the first fragment and transmit it to the SNP.

          to_SNP.dtgm.version := 4;
          to_SNP.dtgm.header_length := 5 + (number bytes of option data/4);
          to_SNP.dtgm.total_length := to_SNP.dtgm.header_length

                                        System Development Corporation
     1 June 1981                   -62-                        IEN 186


                                                     + data_per_fragment;
          to_SNP.dtgm.identifier := from_ULP.identification;
          to_SNP.dtgm.dont_frag_flag := from_ULP.dont_fragment;
          to_SNP.dtgm.more_frag_flag := TRUE;
          to_SNP.dtgm.fragment_offset := 0;
          to_SNP.dtgm.time_to_live := from_ULP.time_to_live;
          to_SNP.dtgm.protocol := from_ULP.protocol;
          to_SNP.dtgm.source_addr := from_ULP.source_addr;
          to_SNP.dtgm.destination_addr := from_ULP.destination_addr;
          to_SNP.dtgm.options := from_ULP.options;
          to_SNP.dtgm.padding := (as needed to end header on 4-octet boundary);

          to_SNP.dtgm.data[0..data_per_fragment-1] :=
                                      from_ULP.data[0..data_per_fragment-1];

       --Set the datagram's header checksum field.
          compute_checksum;

       --Call route to determine the subnetwork address of the destination.
          route;

       --Also set the length and type of service indicators.
          to_SNP.length := to_SNP.dtgm.total_length;
          to_SNP.type_of_service_indicators := to_SNP.dtgm.type_of_service;

       --Request the execution environment to pass the first fragment
       --to the SNP.
          TRANSFER to_SNP to the local subnetwork protocol.


       --Format and transmit successive fragments.

         for j in 1..number_of_fragments-1 loop

            --The header fields remain the same as in the first fragment,
            --EXCEPT for:

              if ("copy" flag present in any options)

              then --put ONLY "copy" options into options fields and
                   --adjust length fields accordingly.

                   to_SNP.dtgm.options := (options with "copy" flag);
                   to_SNP.dtgm.header_length := 5 +
                                          (number of copy options octets/4);

              else --only standard datagram header present

                   to_SNP.dtgm.header_length := 5;

              endif;

                                        System Development Corporation
     1 June 1981                   -63-                        IEN 186


           --Append data and set fragmentation fields.

             if (j /= number_of_fragments-1)

             then --middle fragment(s)

               to_SNP.dtgm.more_frag_flag := TRUE;
               to_SNP.dtgm.fragment_offset := j*number_frag_blocks;
               to_SNP.dtgm.total_length := to_SNP.dtgm.header_length
                                                 + data_per_fragment;
               to_SNP.dtgm.data[0..data_per_fragment-1] :=
                                     from_ULP.data[j*data_per_fragment..
                                 (j*data_per_fragment + data_per_fragment-1)];

             else --last fragment

               to_SNP.dtgm.more_frag_flag := FALSE;
               to_SNP.dtgm.fragment_offset := j*number_frag_blocks;
               to_SNP.dtgm.total_length := to_SNP.dtgm.header_length*4
                                                          + data_in_last_frag;
               to_SNP.dtgm.data[0..data_in_last_frag-1] :=
                                 from_ULP[j*data_per_fragment..
                                 (j*data_per_fragment+ data_in_last_frag-1)];
             end if;

          --Call checksum to set the datagram's header checksum field.
             checksum;

          --Call route to determine the subnetwork address of the destination.
             route;

          --Also set the length and type of service indicators.
             to_SNP.length := to_SNP.dtgm.total_length;
             to_SNP.type_of_service_indicators := to_SNP.dtgm.type_of_service;

          --Request the execution environment to pass this fragment
          --to the SNP.
             TRANSFER to_SNP to the local subnetwork protocol.

       end loop;


     A fragmentation algorithm may vary  according  to  implementation
     concerns  but  every  algorithm  must meet the following require-
     ments:

      1.  A datagram must not be fragmented if dtgm.dont_frag_flag  is
          true.

      2.  Data must be broken on 8-octet boundaries.

                                        System Development Corporation
     1 June 1981                   -64-                        IEN 186


      3.  The minimum fragment size is 68 octets.

      4.  The first fragment must contain all options carried  by  the
          original datagram, except padding and no-op octets.

      5.  The security,  source  routing,  and  stream  identification
          options  (i.e.  marked  with "copy" flag) must be carried by
          all fragments, if present in the original datagram.

      6.  The first fragment must have to_SNP.dtgm.fragment_offset set
          to zero.

      7.  All    fragments,    except    the    last,    must     have
          to_SNP.dtgm.more_frag_flag set true.

      8.  The last fragment must have  the  to_SNP.dtgm.more_frag_flag
          set false.

                                        System Development Corporation
     1 June 1981                   -65-                        IEN 186


     6.3.6.3.9  analyze

     The analyze procedure examines datagrams addressed to IP contain-
     ing  error reports from other IP modules.  In general, error han-
     dling is implementation dependent.  However, guidelines are  pro-
     vided  to  identify  classes  of  errors  and suggest appropriate
     actions.  The errors and error formats  are  defined  in  section
     6.2.15.

     The data effects of this procedure are:

        - Data examined:

               from_SNP.dtgm.protocol
               from_SNP.data

        - Data modified:

               implementation dependent

     For simplicity, it is assumed that the data area can be  accessed
     as a byte array.

     The algorithm:

       --Examine the first and second octets in the data portion
       --of the error datagram to identify the error reported.

          case from_SNP.dtgm[1] of

               when 3 =>  --Destination Unreachable Message

                 --The errors in the "unreachable" class should
                 --should be passed to the ULP indicating data delivery
                 --to the destination is unlikely if not impossible.

                  case from_SNP.dtgm[2] of

                    when 0 =>  --net unreachable

                    when 1 =>  --host unreachable

                    when 2 =>  --protocol unreachable

                    when 3 =>  --port unreachable

                    when 5 =>  --fragmentation needed and don't fragment
                               --flag set
                  end case;


               when 11 =>  --Time Exceeded Message

                                        System Development Corporation
     1 June 1981                   -66-                        IEN 186


                --The "time-out" class of errors are usually not passed to the
                --ULP but should be recorded for network monitoring uses.

                  case from_SNP.dtgm[2] of

                    when 0 =>  --Time to live exceeded in transit

                    when 1 =>  --Fragment reassembly time exceeded

                  end case;


               when 12 =>  --Parameter Problem Message
                  --This error is generated by a gateway IP to indicate
                  --a problem in the options field of a datagram header.

               when 4  =>  --Source Quench Message
                  --This message indicates that a datagram has been
                  --discarded for congestion control.  The ULP should
                  --be informed so that traffic can be reduced.

               when 5  =>  --Redirect Message
                  --This message should result in a routing table update
                  --by the IP module.  It is not passed to the ULP.

               when 8  =>  --Echo Datagram
                  --Use of this message is implementation dependent.

               when 0  =>  --Echo Reply Datagram
                  --Use of this message is implementation dependent.

          end case;

                                        System Development Corporation
     1 June 1981                   -67-                        IEN 186


     6.3.6.3.10  error to ULP

     The error_to_ULP procedure returns an error report to a ULP which
     has  passed  invalid  parameters  or has requested a service that
     cannot be provided.

     The data effects of this procedure are:

        - Parameters:

              error_param : (PARAM_PROBLEM, CAN'T_FRAGMENT,
                              NET_UNREACH, HOST_UNREACH,
                              PROTOCOL_UNREACH, PORT_UNREACH);

        - Data examined:

               implementation dependent

        - Data modified:

               to_ULP.error
               implementation dependent parameters


     The algorithm:

        --The format of error reports to a ULP is implementation
        --dependent.  However, included in the report should be
        --a value indicating the type of error, and some information
        --to identify the associated data or datagram.

          to_ULP.error := error_param;
          --implementation dependent action

                                        System Development Corporation
     1 June 1981                   -68-                        IEN 186


     6.3.6.3.11  error to source

     The error_to_source procedure formats and returns an error report
     to the source of an erroneous or expired datagram.

     The data effects of this procedure are:

        - Parameters:

               error_param : (PARAM_PROBLEM, EXPIRED_TTL,
                              HOST_UNREACH, PROTOCOL_UNREACH);

        - Data examined:

               from_SNP.dtgm

        - Data modified:

               to_SNP.dtgm         to_SNP.local_destination_addrs
               to_SNP.length       to_SNP.type_of_service_indicators

     The algorithm:

          --Format and transmit an error datagram to the source IP.

          to_SNP.dtgm.version         :=  4;      --standard IP version
          to_SNP.dtgm.header_length   :=  5;      --standard header size
          to_SNP.dtgm.type_of_service :=  0;      --least quality of service
          to_SNP.dtgm.identification  :=  select new value;
          to_SNP.dtgm.more_frag_flag  :=  FALSE;
          to_SNP.dtgm.dont_frag_flag  :=  FALSE;
          to_SNP.dtgm.fragment_offset :=  0;
          to_SNP.dtgm.time_to_live    :=  60;     --or value large enough to
                                                  --allow delivery
          to_SNP.dtgm.protocol        :=  3;      --Gateway-Gateway Protocol ID
          to_SNP.dtgm.source_addr     :=  from_SNP.dtgm.destination_addr;
          to_SNP.dtgm.destination_addr := from_SNP.dtgm.source_addr;

        --The data section carries the error message in the first four
        --bytes, and the header and first 64 bytes of data of the
        --bad datagram.

          case error_param of

             where PARAM_PROBLEM =>
               to_SNP.dtgm.data[0] := 12;    --Gateway type = Parameter Problem
               to_SNP.dtgm.data[1] := 0;     --Code = problem with option


             where EXPIRED_TTL =>
               to_SNP.dtgm.data[0] := 11;    --Gateway type = Time Exceeded
               to_SNP.dtgm.data[1] := 0;     --Code = TTL exceed in transit

                                        System Development Corporation
     1 June 1981                   -69-                        IEN 186


             where HOST_UNREACH =>
               to_SNP.dtgm.data[0] := 3;    --Gateway type = Dest. Unreachable
               to_SNP.dtgm.data[1] := 1;    --Code = host unreachable

             where PROTOCOL_UNREACH =>
               to_SNP.dtgm.data[0] := 3;    --Gateway type = Dest. Unreachable
               to_SNP.dtgm.data[1] := 2;    --Code = protocol unreachable

          end case;

        --Below, N is assumed to be the length of the bad datagram's header
        --plus the first 64 bytes of its data section ( 84 <= N <= 124);

          to_SNP.dtgm.data[4..N+3] := from_SNP.dtgm[0..N-1];
          to_SNP.dtgm.total_length := to_SNP.header_length*4 + N;

        --Compute checksum, determine the route for the error datagram,
        --the type of service indicators, and the datagram size for the SNP.

          compute_checksum;
          to_SNP.type_of_service_indicators := 0;
          to_SNP.length := to_SNP.dtgm.total_length;
          route;

        --Request the execution environment to pass the contents of to_SNP
        --to the local subnet protocol for transmission.

          TRANSFER to_SNP to the SNP.

                                        System Development Corporation
     1 June 1981                   -70-                        IEN 186


     6.3.6.3.12  reassembly timeout

     The reassembly_timeout procedure generates an error  datagram  to
     the  source  IP  informing it of the datagram's expiration during
     reassembly.

     The data effects of the procedure are:

        - Data examined:

               state_vector.header
               state_vector.data


        - Data modified:

               to_SNP.dtgm
               to_SNP.length
               to_SNP.type_of_service_indicators
               to_SNP.local_destination_addrs

     The algorithm:

          --Format and transmit an error datagram to the source IP.

          to_SNP.dtgm.version         :=  4;       --standard IP version
          to_SNP.dtgm.header_length   :=  5;       --standard header size
          to_SNP.dtgm.type_of_service :=  0;       --least quality of service
          to_SNP.dtgm.identification  :=  new value selected;
          to_SNP.dtgm.more_frag_flag  :=  FALSE;
          to_SNP.dtgm.dont_frag_flag  :=  FALSE;
          to_SNP.dtgm.fragment_offset :=  0;
          to_SNP.dtgm.time_to_live    :=  60;
          to_SNP.dtgm.protocol        :=  3;      --Gateway-Gateway Protocol ID
          to_SNP.dtgm.source_addr     :=  state_vector.header.destination_addr;
          to_SNP.dtgm.destination_addr := state_vector.header.source_addr;

        --The data section carries the error message in the first four
        --bytes, and the header and first 64 bytes of data of the
        --timed-out datagram.

          to_SNP.dtgm.data[0] := 12;    --Gateway type = Time Exceeded
          to_SNP.dtgm.data[1] := 1;     --Code = fragment reassembly timeout

        --Below, N is assumed to be the length of the expired datagram's header
        --plus the first 64 bytes of its data section ( 84 <= N <= 124 ).

          to_SNP.dtgm.data[4..N+3] := state_vector.data[0..N-1];
          to_SNP.dtgm.total_length := to_SNP.header_length*4 + N;

        --Compute checksum, determine the route for the error datagram,
        --the type of service indicators, and the datagram size for the SNP.

                                        System Development Corporation
     1 June 1981                   -71-                        IEN 186


          compute_checksum;
          to_SNP.type_of_service_indicators := 0;
          to_SNP.length := to_SNP.dtgm.total_length;
          route;

        --Request the execution environment to pass the contents of to_SNP
        --to the local subnet protocol for transmission.

          TRANSFER to_SNP to the SNP.

                                        System Development Corporation
     1 June 1981                   -72-                        IEN 186


     7.  EXECUTION ENVIRONMENT REQUIREMENTS

     This section describes the facilities required  of  an  execution
     environment for proper implementation and operation of the Inter-
     net Protocol.  Throughout this document, the environmental  model
     portrays  each  protocol  as an independent process.  Within this
     model, the execution environment  must  provide  two  facilities:
     inter-process communication and timing.

     7.1  Inter-process communication

     The execution environment must provide an inter-process  communi-
     cation  facility  to  enable  independent  processes  to exchange
     variable-length units of information, called messages.  For  IP's
     purposes,  the IPC facility is not required to preserve the order
     of messages.

     IP uses the IPC facility to  exchange  interface  parameters  and
     data  with  upper  layer protocols across its upper interface and
     the subnetwork protocol across the lower interface.   Sections  3
     and 5 specify these interfaces.

     7.2  Timing

     The execution environment must provide  a  timing  facility  that
     maintains  a  real-time  clock  with units no coarser than 1 mil-
     lisecond.  A process must be able to set a timer for  a  specific
     time period and be informed by the execution environment when the
     time period has elapsed.  A process must also be able to cancel a
     previously set timer.

     Two IP mechanisms use the timing facility.  The  internet  times-
     tamp  carries  timing  data in millisecond units.  The reassembly
     mechanism uses timers to limit the lifetime of a  datagram  being
     reassembled.   In  the  mechanism  specification this facility is
     called TIMEOUT.

                                        System Development Corporation
     1 June 1981                   -73-                        IEN 186


     8.  BIBLIOGRAPHY

      1.  "DCEC Protocols Standardization Program  Preliminary  Archi-
          tecture  Report"  TM-7038/200/00,  Contract No. DCA100-80-C-
          0044, February 1981.

      2.  "Protocol Specification  Guidelines",  TM-7038/204/00,  Con-
          tract No. DCA100-80-C-0044, June 1981.

      3.  V. Cerf and R. Kahn, "A Protocol for Packet  Network  Inter-
          connection", IEEE Transactions on Communications, May 1974.

      4.  J. Postel (ed.), "DoD Standard Internet  Protocol",  Defense
          Advanced  Research  Projects  Agency, Information Processing
          Techniques Office, RFC760, IEN128, January 1980.

      5.  J. Postel (ed.), "DoD Standard Transmission  Control  Proto-
          col", Defense Advanced Research Projects Agency, Information
          Processing Techniques Office, RFC761, IEN129, January 1980.

      6.  V. Cerf and P. Kirstein, "Issues in Packet-Network Intercon-
          nection",  Proceedings  of the IEEE, November 1978, pp.1386-
          1408.

      7.  P.T. Kelly, "Public Packet Switched Data Networks,  Interna-
          tional  Plans  and  Standards",  Proceedings  of  the  IEEE,
          November 1978, pp.1539-1549.

      8.  D. Boggs, J. Shoch, E.  Taft,  and  R.  Metcalfe,  "Pup:  An
          Internetwork  Architecture", IEEE Transactions on Communica-
          tions, April 1980, pp.612-624.

      9.  J. Postel, "Internetwork Protocol Approaches", IEEE Transac-
          tions on Communications, April 1980, pp.604-611.

     10.  J. Shoch, "Inter-Network Naming, Addressing,  and  Routing",
          COMPCON, IEEE Computer Society, Fall 1978.

     11.  J. Shoch, "Packet Fragmentation in Inter-Network Protocols",
          Computer Networks, vol.3, no.1, February 1979.

     12.  J. Postel, "Address Mappings", IEN 115, USC/Information Sci-
          ences Institute, August 1979.

     13.  J.  Postel,  "Assigned   Numbers",   RFC   762,   IEN   127,
          USC/Information Sciences Institute, January 1980.

                                        System Development Corporation
     1 June 1981                   -74-                        IEN 186


     9.  GLOSSARY

     Destination
     An IP header field  containing  an  internet  address  indicating
     where a datagram is to be sent.

     datagram
     A self-contained package of data carrying enough  information  to
     be  routed from source to destination without reliance on earlier
     exchanges between source or destination and the transporting sub-
     network.

     datagram fragment
     The result of fragmenting a datagram, also simply referred to  as
     a  fragment.   A datagram fragment carries a portion of data from
     the larger original, and a copy of the original datagram  header.
     The  header  fragmentation  fields  are  adjusted to indicate the
     fragment's relative position within the original datagram.

     datagram service
     A datagram, defined above, delivered  in  such  a  way  that  the
     receiver  can  determine the boundaries of the datagram as it was
     entered by the source.  A datagram  is  delivered  with  non-zero
     probability  to  the  desired destination.  The sequence in which
     datagrams are entered into the subnetwork  by  a  source  is  not
     necessarily preserved upon delivery at the destination.

     DF
     Don't Fragment flag: An IP header field that when set true prohi-
     bits  an  IP  module  from  fragmenting  a datagram to accomplish
     delivery.

     fragmentation
     The process of breaking the data within a datagram  into  smaller
     pieces  and  attaching  new  internet  headers  to  form  smaller
     datagrams.

     Fragment Offset
     A field in the IP header  marking  the  relative  position  of  a
     datagram fragment within the larger original datagram.

     gateway
     A device, or pair of devices, which interconnect two or more sub-
     networks  enabling  the  passage  of  data from one subnetwork to
     another.  In this architecture, a gateway usually contains an  IP
     module, a Gateway-to-Gateway Protocol (GGP) module, and a subnet-
     work protocol module (SNP) for each connected subnetwork.

     header
     Collection of control information transmitted with  data  between
     peer entities.

                                        System Development Corporation
     1 June 1981                   -75-                        IEN 186


     host
     A computer which is a source or destination of messages from  the
     point of view of the communication subnetwork.


     Identification
     An IP header field used in reassembling fragments of a datagram.

     IHL
     Internet Header Length: an IP header field indicating the  number
     of 32-bit words making up the internet header.

     Internet address
     A four octet (32 bit) source or destination address composed of a
     Network  field  and  a REST field.  The latter usually contains a
     local subnetwork address.

     internet datagram
     The package exchanged between a pair of IP modules.  It  is  made
     up of an IP header and a data portion.

     local address
     The address of a host within a subnetwork.  The actual mapping of
     an internet address onto local subnetwork addresses is quite gen-
     eral, allowing for many to one mappings.

     local subnetwork
     The subnetwork directly attached to host or gateway.

     MF
     More Fragments flag: an IP  header  field  indicating  whether  a
     datagram fragment contains the end of a datagram.

     module
     An implementation, usually in software, of a  protocol  or  other
     procedure.

     MTU
     Maximum Transmission Unit: a  subnetwork  dependent  value  which
     indicates the largest datagram that a subnetwork can handle.

     octet
     An eight bit byte.

     Options
     The optional set of fields at the end of the IP  header  used  to
     carry  control  or  routing  data.   An Options field may contain
     none, one, or several options, and each  option  may  be  one  to
     several  octets  in  length.  The options allow ULPs to customize
     IP's services.  The options are also useful in testing situations
     to carry diagnostic data such as timestamps.

                                        System Development Corporation
     1 June 1981                   -76-                        IEN 186


     packet
     The unit of data transmitted by  a  packet-switched  network.   A
     packet  usually contains nested control information and data from
     the upper layer protocols using the subnetwork.

     packet network
     A network based on  packet-switching  technology.   Messages  are
     split  into small units (packets) to be routed independently on a
     store and  forward  basis.   This  packetizing  pipelines  packet
     transmission to effectively use circuit bandwidth.

     Padding
     An IP header field, an octet in length, inserted after  the  last
     option field to ensure that the data portion of a datagram begins
     on a 32-bit word boundary.  The Padding field value is zero.

     Protocol
     An internet header field used to identify the upper layer  proto-
     col  that  is the source and destination of the data within an IP
     datagram.

     Precedence
     One of the service quality parameters provided  by  the  type  of
     service  mechanism.  Precedence is a relative measure of datagram
     importance.  This parameter can be set to  one  of  five  levels:
     routine,  priority,  immediate,  flash,  or  flash  override.  It
     appears as a three bit field within the Type of Service field  in
     the IP header.

     reassembly
     The process of piecing together datagram fragments  to  reproduce
     the original large datagram. Reassembly is based on fragmentation
     data carried in their IP headers.

     Reliability
     One of the service quality parameters provided  by  the  type  of
     service  mechanism.   The reliability parameter can be set to one
     of four levels: lowest, lower, higher, or highest.  It appears as
     a  two  bit  field  within  the  Type  of Service field in the IP
     header.

     reliability
     A quality of data transmission  defined  as  guaranteed,  ordered
     delivery.

     Rest
     The three octet field of the internet address usually  containing
     a local address.

     segment
     The unit of data exchanged by TCP modules.  This term may also be
     used  to  describe  the  unit  of  exchange between any transport

                                        System Development Corporation
     1 June 1981                   -77-                        IEN 186


     protocol modules.

     Source
     An IP  header  field  containing  the  internet  address  of  the
     datagram's point of origin.

     stream delivery service
     The special handling required for a class  of  volatile  periodic
     traffic  typified  by  voice.   The  class  requires  the maximum
     acceptable delay to be only slightly larger than the minimum pro-
     pagation  time,  or  requires  the  allowable  variance in packet
     interarrival time to be small.

     SNP
     SubNetwork Protocol: the  protocol  residing  in  the  subnetwork
     layer  below  IP  which  provides data transfer through the local
     subnet.  In some systems, an  adaptor  module  must  be  inserted
     between  IP  and  the subnetwork protocol to reconcile their dis-
     similar interfaces.

     TCP
     Transmission Control Protocol:  a  transport  protocol  providing
     connection-oriented,  end-to-end  reliable  data  transmission in
     packet-switched computer subnetworks and internetworks.

     TCP segment
     The unit of data exchanged between TCP modules (including the TCP
     header).

     Total Length
     An IP header field containing the number of octets in an internet
     datagram, including both the IP header and the data portion.

     Type of Service
     An IP header field containing the  transmission  quality  parame-
     ters:  precedence level, reliability level, speed level, resource
     trade-off (precedence vs.  reliability),  and  transmission  mode
     (datagram vs. stream).  This field is used by the type of service
     mechanism which allows ULPs to select the quality of transmission
     for a datagram through the internet.

     ULP
     Upper Layer Protocol: any protocol above IP in the layered proto-
     col  hierarchy  that uses IP.  This term includes transport layer
     protocols, presentation layer protocols, session layer protocols,
     and application programs.

     user
     A generic term identifying a process or person employing a proto-
     col.   In IP's case, this term may describe a transport protocol,
     a presentation layer protocol, a session layer  protocol,  or  an
     application program.

                                        System Development Corporation
     1 June 1981                   -78-                        IEN 186


     Version
     An IP header field indicating the format of the IP header.



mirror server hosted at Truenetwork, Russian Federation.