MULTICS TECHNICAL BULLETIN                                 MTB769

To:       MTB Distribution

From:     John Hunter

Date:     October 14, 1987

Subject:  Implementing Internet Protocol on Multics

               -----------------------------------

This  MTB describes work  which must be  done to have  a complete
version of the DARPA Internet Protocol on Multics.

               -----------------------------------

Comments on this MTB should be sent to the author -
          via Multics mail to:
                    Hunter%pco@bco
          via telephone to:
                    John Hunter, STMS (602) 862-3594

          via forum on System-M to:
                    >exl>net>mtgs>IP_implementation (ip)

_________________________________________________________________

Multics project  internal documentation; not to  be reproduced or
distributed outside the Multics project without permission of the
Director of STMS.


MTB769                               INTERNET PROTOCOL ON MULTICS

                             CONTENTS

                                                         Page

   1:  Introduction  . . . . . . . . . . . . . . . . . . . .     1
   2:  Internet Protocol (IP)  . . . . . . . . . . . . . . .     1
   3:  Areas of Non-Compliance . . . . . . . . . . . . . . .     2
   3.1:  ICMP  . . . . . . . . . . . . . . . . . . . . . . .     3
   3.2:  Packet Fragmentation and Reassembly . . . . . . . .     3
   3.3:  The IP Options  . . . . . . . . . . . . . . . . . .     4
   4:  Additional Work . . . . . . . . . . . . . . . . . . .     5
   4.1:  Testing . . . . . . . . . . . . . . . . . . . . . .     5
   4.2:  Logic Errors  . . . . . . . . . . . . . . . . . . .     6
   4.3:  Site Dependencies . . . . . . . . . . . . . . . . .     6
   5:  Additional Benefits . . . . . . . . . . . . . . . . .     6
   Appendix A:  Glossary . . . . . . . . . . . . . . . . . .     7
   Appendix B:  IP Routing and Protocols . . . . . . . . . .     9
   B.1:  Protocols . . . . . . . . . . . . . . . . . . . . .     9
   B.2:  Internet Routing and Architecture . . . . . . . . .     9


INTERNET PROTOCOL ON MULTICS                               MTB769

1:  INTRODUCTION

     This MTB describes work which  must be done to implement the
     DARPA  Internet Protocol   on Multics.   This implementation
     will meet all DARPA requirements.

     References   are  made   in   this   MTB  to   the  ARAPANET
     specification  documents  known   as  Requests  for  Comment
     (RFCs).   The RFCs  mentioned in  this MTB  may be  reviewed
     online  on System-M  in the  >exl>net>rfcs directory.   This
     directory does not contain a complete collection of all RFCs
     in existance.  However, as  noted above, all RFCs referenced
     in this MTB are present in the >exl>net>rfcs directory.

     It  is  recognized  that  not  all  readers  of this MTB are
     familiar with  network terminology.  A glossary  is included
     at the end of this document  to provide a quick reference to
     that  terminology.  Note  that network  terminology may also
     include  terms that  have completely  different meanings  in
     other  areas  of  computer  applications.   An  appendix  is
     included to summarize the  signifcance of Internet protocols
     and  to summarize  the routing  of packets  in the Internet.
     The  reader  who  is  unfamiliar  with  Internet routing and
     network  terminology  is  strongly  encouraged  to  read the
     glossary and the appendix before continuing.

2:  INTERNET PROTOCOL (IP)

     The  Internet  Protocol  (IP)  describes  procedures  to  be
     observed   by    hosts   in   interconnected    systems   of
     packet-switched   computer  communication   networks.   This
     protocol  is  specified   in  RFC791,  "Internet  Protocol".
     RFC791 describes  the format and meaning  of packets, packet
     headers  and  network   addresses.   Strategies  for  packet
     fragmentation, reassembly, and routing are also described.

     IP provides  an unreliable datagram  service and is  used by
     many  higher-level protocols   for exchanging  messages with
     their peers on other Internet  hosts.  IP is used to support
     such  applications  as  reliable  message  service, resource
     sharing,  remote  login,  remote  file  transfer, electronic
     mail, and electronic news services.

     The DARPA Internet protocols are the most widely implemented
     internetwork protocols in the  industry at this time.  These
     protocols   are  often   referred  to   as  "TCP/IP".   This


MTB769                               INTERNET PROTOCOL ON MULTICS

     terminology is misleading.  TCP is a DARPA Internet protocol
     which  provides a  reliable message  service on  top of  the
     unreliable  datagram  service  of  IP.   TCP/IP  refers to a
     two-layered  protocol structure   which provides  a reliable
     message service.   TCP/IP does not accurately  represent the
     full functionality or structure of DARPA Internet protocols.
     For example, UDP is a DARPA Internet protocol which provides
     an  application with  unreliable datagram  service.  UDP  is
     also run  on top of  IP.  For the  purposes of this  MTB the
     more general terminology "Internet protocols" will be used.

     A  version  of  IP  exists   on  System-M  in  the  >exl>net
     hierarchy.  This version was  implemented in the early 1980s
     and periodically updated.  The code  was reviewed at STMS to
     determine   whether  it   was  in   compliance  with   DARPA
     requirements for hosts  implementing the Internet protocols.
     These  requirements are  enumerated in  RFC1010 -  "Official
     Protocols".  Several areas of non-compliance were detected.

     This  MTB  describes  the  areas  of  non-compliance and the
     actions necessary to bring  the IP implementation to current
     standard.   The  resulting  design  proposals  will  require
     several MTBs and these are noted where appropriate.

3:  AREAS OF NON-COMPLIANCE

     Non-compliance was noted in 3 areas.

     o    Internet Control Message Protocol (ICMP)

     o    Packet fragmentation and reassembly

     o    IP options

     Non-compliance  to  requirements   refers  to  protocols  or
     portions of  protocols which are  not implemented in  the IP
     implementation at  hand.  These areas of  non-compliance and
     the  steps  which  must  be  completed  to  resolve them are
     detailed  below.  All  of these   action items  will be  the
     subject of future MTBs.   Therefore, only brief descriptions
     of  the  problems  and  their  solutions  are  given  below.


INTERNET PROTOCOL ON MULTICS                               MTB769

     Detailed descriptions are deferred to the future MTBs.

3.1:  ICMP

          Internet Control Message Protocol (ICMP) is detailed in
          RFC792,   "Internet  Control   Message  Protocol"   and
          augmented  in  RFC950,  "Internet  Standard  Subnetting
          Procedure".   The job  of  ICMP  is to  provide routing
          control messages and error  reports.  These are used at
          the  IP  level  for  tuning  routing  decisions and for
          requesting  information about  the current  logical and
          physical connectivity  of the Internet.   ICMP utilizes
          IP  to send  and receive   messages.  IP  uses ICMP  to
          advise other  hosts of routing conditions  at the local
          host.   IP  and  ICMP  are  tightly  connected.   No IP
          implementation   is  considered  complete   without  an
          implementation of ICMP [RFC791].   ICMP is required for
          all Internet hosts [RFC1010].

          There  is  no  implementation  of  ICMP  in our current
          version of  the Internet protocols.   An implementation
          of  ICMP  must  be  developed  and  integrated into the
          current collection of Internet programs.  Some work has
          begun on the latter task  during the analysis of the IP
          implementation.  This  work consisted of  noting points
          in the  code where conditions warrant  invoking ICMP to
          send  messages.  Once  the protocol  is implemented, we
          will be able  to receive and act on  ICMP messages from
          remote  hosts.   We  will  also  be  able  to send ICMP
          messages  from Multics  hosts.  The  design details  of
          this implementation  will be included in  a future MTB.
          The planned implementation  will encompass the protocol
          specifications   set   forth    in   RFC792   and   the
          augmentations  for supporting  subnetting specified  in
          RFC950.

3.2:  Packet Fragmentation and Reassembly

          RFC791,  "Internet Protocol",  describes the  following
          problem and its solution.  When  a packet arrives at an
          input  interface and  is passed  to IP,  IP must decide
          which output  interface should receive the  packet.  It
          may be the case that  the packet must be forwarded over
          another  network to which  our host is  connected.  The
          carrying capacity  of this network may be  too small to
          send  the packet in  one piece.  Therefore,  the packet
          may  be fragmented  and forwarded  through the network.


MTB769                               INTERNET PROTOCOL ON MULTICS

          Sufficient  information  is  preserved  in  the  packet
          header  so  that  the  packet  may  be  reassembled  on
          reaching its destination.  It  is also possible for the
          user to  specify in the  packet header that  the packet
          should  not be   fragmented.  Packet  fragmentation and
          reassembly functionality is required by RFC791.

          The current implementation of  IP does not provide this
          functionality.  Several suggested  algorithms exist for
          performing packet fragmentation  and reassembly and are
          published in RFC791 and  RFC815.  These algorithms will
          be   analyzed   and   an   implementation   of   packet
          fragmentation  and  reassembly  will  be  designed  and
          executed.  This  work will be  the subject of  a future
          MTB.

3.3:  The IP Options

          RFC791  specifies  network   parameters  which  may  be
          applied  to packets sent  by a host.   These parameters
          allow an applications process  to customize the service
          provided by  IP.  The parameters govern  the setting of
          precedence  for  IP  datagrams,  speed  and  urgency of
          delivery   of   datagrams,   route   specification   of
          datagrams,  security  labelling  of  IP  datagrams, and
          other  performance  and  service  parameters.   Some of
          these service parameters are  set in required fields of
          the IP  header, others are  set in an  options field of
          the IP  header.  The options  field is optional  in the
          sense  that  this  field  is  not  required  in  all IP
          datagrams.  The implementation of  the options field in
          the host IP module is not optional, however.

          The  current version of  IP only partially  attempts to
          implement the options field.   The upper level protocol
          which utilizes the services of  IP may specify that the
          security  option is  present in  an outbound  datagram.
          The security  options field will be included  in the IP
          header  as a  result.  No   provision is  made for  the
          remaining  options.  In  addition, when  the current IP
          module receives a packet  with the security option set,
          no  processing  occurs  other  than  to  note  that the
          security  option  is  present.   The  new  version must
          provide an interface to the upper level protocols which
          allows all options to be specified with a datagram.  In
          addition, all datagrams received  with options set must
          have those options processed  in an appropriate manner.
          This will be the subject of a future MTB.


INTERNET PROTOCOL ON MULTICS                               MTB769

4:  ADDITIONAL WORK

     Additional work  must be done on  the current implementation
     to  ensure the  correct functioning  of the  IP package.   A
     suite of tests must be  developed to ensure that any changes
     performed  on  the  current  version  of  IP  do  not have a
     negative  impact  on  the  proper  functioning of previously
     correct code.  These tests  must also ensure the correctness
     of  newly implemented  functionality.  Logic  errors in  the
     current  version, detected  in the  review process,  must be
     corrected.  Site dependencies in the current version must be
     removed.   A routing  server must   be developed  to aid  in
     removing these site dependencies.

4.1:  Testing

          The revised code can be tested without having an actual
          connection to the Internet.   One focus of testing will
          be  on  ensuring  that  packets  are  presented  to the
          correct network  interface in proper format.   This can
          be done  by providing a wrapper environment  for the IP
          modules  within  which  IP  input  and  output  can  be
          observed.   Standard I/O  interfaces could  be used  to
          construct  the  wrapper  environment.   Other  foci  of
          testing will be

          o    Appropriate actions on receiving ICMP messages

          o    Sending appropriate ICMP messages

          o    Fragmentation and reassembly

          o    Packet routing

          o    Setup and shutdown of the IP environment

          Once we  are assured of the correct  functioning of the
          code in a closed environment,  we can begin a series of
          live tests, either from BCO, or from Phoenix, utilizing
          a  future  Internet  connection.   Details  of proposed
          tests  will be  given in  future MTBs  dealing with the
          changes and additions proposed here.


MTB769                               INTERNET PROTOCOL ON MULTICS

4.2:  Logic Errors

          Several   logic  errors   were  noted   and  informally
          documented in the review process of the current version
          of IP.  These errors will  be corrected and the results
          of  those  corrections  will  be  tested.   To  provide
          another  layer of error  trapping, it is  proposed that
          the new  version be processed through  standard Multics
          installation procedures.

4.3:  Site Dependencies

          The current version contains  some site dependencies in
          its routing  management.  Packets with  addresses which
          cannot be resolved as local or known addresses are sent
          to  MIT for  further routing.   An attempt  was made to
          remedy this  site dependency in an  earlier revision of
          the IP module.  This effort was not completed, however.
          The  key element  missing is  a routing  server for the
          host.

          The current version of IP  does not provide for routing
          to be  done on the  host.  As noted  above, all packets
          for  other  hosts  are  routed   to  MIT.   This  is  a
          non-robust approach to routing  which must be addressed
          in  the new  version of  IP.  A  general routing server
          must be  developed which is  adaptable to the  needs of
          the individual host site.  This  will be the subject of
          a future MTB.

5:  ADDITIONAL BENEFITS

     It  is the  goal of   STMS to  have a  complete, functioning
     network package as the result of the efforts detailed above.
     In   addition  to   the  software,   it  is   expected  that
     documentation  and software tools  support will grow  out of
     this  effort.  This  will  aid  customers in  developing and
     analyzing  the  performance  of  their  own network systems.
     Future effort  at STMS may then be  focussed on implementing
     new network products to  enhance the networking abilities of
     our customers and to  meet their networking needs.  Specific
     areas of future development include interfacing the Internet
     protocols  with MNA, and  development of network  drivers to
     support internetworking for hosts  whose local network is an
     Ethernet.


INTERNET PROTOCOL ON MULTICS                               MTB769

APPENDIX A:  GLOSSARY

Addresses -  A means of encoding  the identity and location  of a
     host.  ARPANET addresses are  represented as 32-bit strings.
     Encoded  within the  string is  the number  assigned to  the
     network  where a  host resides  and the  number within  that
     network assigned to the host.
ARPA - Advanced Research Projects  Agency.  Sponsoring agency for
     the ARPANET.  ARPA is now known as DARPA (see below).
ARPANET - Packet communications network  sponsored by ARPA in the
     early 1970s.   The oldest and largest  packet communications
     network in existence.
DARPA - Defense  Advanced Research Projects Agency.   Sponsors of
     the DARPA Internet Program.  Formerly known as ARPA.
Datagram  - The  basic data  unit in  the Internet  Protocol.  To
     cross a  physical network, a  datagram is encapsulated  in a
     packet.
Datagram Service - An approach to sending packets in a network in
     which  each packet  is independant  of all  others.  A  good
     analogy  to datagram  service  is  the postal  system.  Each
     letter being handled by the postal service is independant of
     all other letters.
Host -  A machine  in a   computer network  intended to  run user
     programs.    Hosts  in   a  network   are  connected   by  a
     communications subnet.  The job of the communications subnet
     is to carry messages from host to host.
Internet - The Internet  system consists of interconnected packet
     networks supporting communication among host computers using
     Internet protocols.  A network of networks.
Packet  -  The  basic  data  unit  in  a  network.   The  unit of
     transmission in a physical network.
Protocol   -  The  means   by  which  processes   organize  their
     cooperation.  Protocols  may prescribe formats  for messages
     and addresses  and ways in which  internetwork communication
     and transmission is synchronized and otherwise controlled.
RFC - Request  for  Comment.   A  document  used  by  the ARPANET
     community for proposing and publishing standards for ARPANET
     network  communications.  RFCs  are numbered  and are  often
     referred  to  as  "RFCxxx"  where  "xxx"  refers  to the RFC
     number.
Routing - Packets arrive at a host on an input interface and must
     then be  passed on to  an output interface.   The process of
     checking  the packet  destination and  deciding which output
     interface to pass the packet on to is called routing.
Unreliable Datagram  Service - A  datagram service is  said to be
     unreliable if it does not guarantee that all packets will be
     delivered.  Further, an unreliable datagram service does not
     guarantee that packets will  arrive in any particular order.
     Note that unreliability indicates  that the service provided
     is primitive, not that it is bad .  Again, postal service is
     a good analogy.  When a letter is lost in the postal system,
     the sender  has no way of  knowing.  It is not  customary to


MTB769                               INTERNET PROTOCOL ON MULTICS

     send multiple copies of a  letter until the letter's arrival
     is acknowledged.  When two letters are sent on the same day,
     it is impossible  to guarantee the order in  which they will
     arrive.


INTERNET PROTOCOL ON MULTICS                               MTB769

APPENDIX B:  IP ROUTING AND PROTOCOLS

     The purpose  of this appendix is to  provide some background
     into ARPANET  architecture and design issues.   The appendix
     is intended to answer the following questions.

          1) What is  a protocol and what do we  do with one once
          we've read it?

          2) How  do messages get  from source to  destination in
          the Internet?

     For a more thorough description  of the Internet system, the
     reader is referred to RFC791, which describes the system and
     details the role of gateways in the Internet system.

B.1:  Protocols

          DARPA  Internet   protocols  describe  the   format  of
          information  packets to  be sent  through the Internet.
          Where necessary, a sequence of messages to be exchanged
          between  processes   may  be  specified.    The  actual
          implementation of  a protocol is not  prescribed by the
          protocols, however.  The role of a protocol can be seen
          as  a  statement  of  conventions  to  be  observed  by
          participating    hosts   in    order   to    facilitate
          communications   in   the    Internet.    It   is   the
          responsibility  of  the  implementor  to  see  that the
          individual  implementation  performs  in  a  reasonable
          manner.  For  example, the ICMP protocol  (RFC 792, RFC
          950) describes the format of messages by which a source
          host  may be  advised of  events in  the Internet which
          effect the transmission of  packets.  The protocol also
          specifies  the  conditions  under  which  ICMP messages
          should be sent.  The protocol  does not, in most cases,
          specify what action must be  taken once a host receives
          an   ICMP   message.     The   protocol   also   leaves
          specification of the local  interfaces to ICMP strictly
          up to the implementor.

B.2:  Internet Routing and Architecture

          "The   Internet  system   consists  of   a  number   of
          interconnected packet networks supporting communication
          among  host computers   using the  Internet protocols."


MTB769                               INTERNET PROTOCOL ON MULTICS

          [RFC 1009] The two protocol implementations required of
          all  hosts  are  the  Internet  Protocol  (IP)  and the
          Internet   Control   Message   Protocol   (ICMP).   The
          constituent  networks may  be of  any configuration and
          need  not rely on  Internet protocols to  send messages
          within the local network.   The Internet protocols come
          into  play when a  process wishes to  send a packet  of
          information to  a process on  another network, or  to a
          process  resident on  a host  on the  local network who
          also recognizes the Internet protocols.

          In order for hosts to communicate, they must have a way
          to  identify  each  other.   This  is  achieved through
          Internet  addresses.   Each  network  and  host  on the
          Internet  has an  address.   This  address is  a 32-bit
          field  which  encodes  the  network  on  which the host
          resides,  and a  number identifying  the host.   If the
          network  has  logical  subnets,  then  the  subnets are
          identified by applying a  mask to the Internet address.
          The most common practice is to reserve a portion of the
          host  address for  the  subnet  address.  In  this way,
          several subnets can share  the same Internet address in
          a  manner transparent  to the  outside world.  Internet
          addresses of the source and destination of all messages
          are included in all properly formed Internet messages.

          The Internet protocols have  a layered structure.  If a
          local  application process  wishes to  communicate with
          another  process, it passes  its message to  a protocol
          module  which  provides  the  service  required.   This
          protocol   module  must    now  communicate   with  the
          corresponding protocol module  at the destination host.
          This is done by constructing a header and concatenating
          it with  the application process message.   This header
          will  provide  enough  information  for  the  receiving
          protocol module to forward  the original message to the
          receiving  user process.   Having constructed  this new
          message, the  protocol now passes  it to a  lower level
          protocol,   which   constructs   a   new   header   and
          concatenates  it with the  message it has  received and
          passes  this message to  a lower level  protocol.  This
          process  is repeated until  the message arrives  at the
          protocol module which interfaces  to the local network.
          This  protocol  module  sends  the  message through the
          local network  to an Internet  gateway which is  on the
          local  network.  The  message then  passes through  the
          Internet  to   the  destination  host.    The  original
          message,   encapsulated   by   the   headers   it   has
          accumulated, is known as a packet.


INTERNET PROTOCOL ON MULTICS                               MTB769

          The  packet is  received by  the lowest  level protocol
          module  at the  destination host.   This module removes
          the   header  from   the  message   and  extracts   the
          information  it  needs  from  the  header  to  pass the
          message  (minus  the  lower-level  header)  up  to  the
          protocol  at the next  highest level.  This  process is
          repeated until  the message arrives at  the destination
          process on the destination host.

          The lowest level Internet  protocol is IP.  IP provides
          an unreliable datagram service.   IP packets may arrive
          out of order, may be lost,  or may be damaged.  If more
          reliable communication is needed,  it is implemented by
          a   higher  level  protocol   such  as  TCP.    If  the
          applications process requires  only a datagram service,
          it is provided by the higher level protocol UDP.  Below
          IP  are   the  non-Internet  protocols   which  support
          communication  within the  local network.   An Internet
          application which required reliable communication could
          be built on top of TCP.   TCP itself is built on top of
          IP [See RFC791, page 5].

          Once a packet arrives at the IP module, the destination
          address is  checked.  If the destination  happens to be
          on  this host,  then the   packet is  forwarded to  the
          appropriate upper  level protocol.  The message  may be
          destined for  another host, however.  At  this point, a
          local  database  is  consulted  to  determine where the
          packet should go next.  This decision process is called
          routing.  The routing  decision involves deciding where
          the packet should be passed on the local network to get
          it one  step closer to its destination.   If the packet
          must go outside the local network, it must be routed to
          another  host  which  is  connected  to  both the local
          network and at least one other network.  Such a host is
          known as a gateway.  A packet traverses the Internet by
          being  routed   from  gateway  to  gateway.    At  each
          intermediate  gateway,  the   IP  module  receives  the
          message and forwards it to  the next gateway across the
          intervening local network [See RFC791,page 6].