Multics Technical Bulletin                                MTB-748
Networking Overview

To:       Distribution

From:     Richard J.C.  Kissel

Date:     04/02/86

Subject:  Overview of the New Multics Networking Architecture


    An overview of the  new Multics Networking Architecture (MNA)
is  presented.  This includes  an overview of  the changes to  be
made  for  the  user  interface,  changes  to  the administrative
system, and  internal Multics support changes.  This  is meant to
be  an  introduction  to  the  networking  architecture  and  its
terminology and serves as a prerequisite for understanding future

Comments should be sent to the author:

via Forum:
   >udd>m>rjck>mtgs>Multics_Networking (mnet).

via Multics Mail:
   Kissel.Multics on all systems

via telephone:
   (HVN) 492-9320 or (617) 492-9320


Multics  project  internal  working  documentation.   Not  to  be
reproduced or distributed outside the Multics project without the
consent of the author or the author's management.

Multics Technical Bulletin                                MTB-748
Networking Overview


     This  MTB introduces the  concepts and issues  involved with
designing  and implementing  networking support  on Multics.  The
following paragraphs from MTB-607 ("Problems  With MCS" by C.  A.
Hornig,  1/26/83) summarize  the  reasons  for embarking  on this
effort now.

     "At the  present time there  is a great  deal of demand
     for new  communications functionality.  This  demand is
     coming  largely  from  two  sources,  the  window/video
     system development effort and  the expansion of Multics
     networking capabilities.  The window/video system needs
     real-time   input   editing   without   central  system
     overhead.   Network  implementers  need  extremely high
     throughput,  better   response  time,  and   also  less
     overhead.  These needs cannot be met within the current
     system.  They can and should  be met by any replacement
     for it.

     Another  requirement  which  must  be  met  is that the
     replacement  allow much more  architectural flexibility
     then  the  current  MCS.   We  need  to  support a wide
     variety of Honeywell and foreign equipment through many
     different   communication  media.   In   addition,  the
     concept of 'distributed' front-end processors should be
     supported.  This  would permit processing  performed by
     the FNP to be done by a FNP at a remote site.  This FNP
     would communicate  with the local Multics  FNP over any
     of a number of communications media.  This allows us to
     distribute communications processing  power where it is
     needed,   and   eliminate   unnecessary  communications


     Our    current   communications    support,   the    Multics
Communications System (MCS), is  well designed to support locally
connected or  dialed up terminals.  However,  terminals connected
through networks, and computer to computer communications through
networks, are not well supported.  MTB-607 describes the problems
with MCS in a networking environment.  The basic problems are:

   o Obsolete  frontend  hardware   and  software.   The  current
     frontend is  based on the Datanet  355 hardware architecture
     which  is  being  replaced   within  Honeywell  by  the  DN8
     frontend, based  on Level 6 hardware.   The current frontend
     must be programmed in a macro/table-driven assembly language
     (based on  MAP355) which is nearly impossible  to enhance or

MTB-748                                Multics Technical Bulletin
                                              Networking Overview

   o Static connection  descriptions used by ring  0 multiplexers
     (basically  the  CMF).   Most  networks  that  Multics  must
     support, create and  destroy connections dynamically, either
     at the request  of the network for incoming  requests, or at
     the request of the Multics user for outgoing requests.

   o TTY  I/O module  problems and  terminal management problems.
     The  current TTY  interface does   not support  many of  the
     operations  that are needed  to interface to  networks, e.g.
     record  oriented  communication  (as  opposed  to  streams),
     direct manipulation of network  parameters (for instance PAD
     parameters  on X.25  networks), etc.   The current  terminal
     management  (i.e.    input/output  conversion,  translation,
     canonicalization, etc.)  is handled in  ring 0, and thus, is
     not  available  for  use  by  a  network terminal management
     protocol such as is used on a DSA network.

   o Current  administration and  control  is  not suited  to the
     dynamic nature of networks.  Again, the static nature of the
     CMF makes administrative (and  Answering Service) control of
     dynamic  network connections  difficult.  For  instance, all
     channels  have to be  predefined in the  CMF, even though  a
     network may support a very large (or even unknown) number of


     The  goal  of  this  effort  is  to  provide  a  "networking
platform"  on   Multics.   This  "networking  platform"   is  the
architecture  (and implementation)  of "real"  network support on
Multics.  In particular, the first  goal of the effort is support
of DSA (Honeywell's Distributed  Systems Architecture) on Multics
using   a  DN8   frontend.   However,   the  Multics   Networking
Architecture  (MNA) is  not DSA   specific and  must support  any
network  which might  be  connected  to Multics,  e.g.  Internet,
X.25, Hyperchannel, ChaosNet, CSNet, etc.

     There are  some major constraints that must  be satisfied by
the MNA:

   o MCS  must continue to  work with its  current functionality.
     This includes both the Multics side and the frontend side of
     MCS, since  there is no  current plan to  build a functional
     replacement for  the current DN6xxx frontend.   This will be
     done  by  leaving  MCS  (as  well  as  all of its supporting
     functions  in  the  Answering   Service,  user  ring,  etc.)
     intact.  It may be possible  to migrate (in a user invisible
     fashion) the MCS functionality to MNA as time permits.

Multics Technical Bulletin                                MTB-748
Networking Overview

   o MNA must be a "distributed"  architecture.  That is, it must
     be  possible to distribute  functions and services  from the
     host  to:   local   frontends,  remote  frontends,  personal
     workstations, intelligent  terminals, etc.  It  must support
     networks  connected to  Multics through  PSIA channels (e.g.
     the Hyperchannel) or other hardware channels, as well as the
     normal case of networks  connected through a local frontend.

   o Multics  security  must  not  be  compromised  by MNA.  This
     includes AIM security.

   o Implementation of MNA must not require changes in user code,
     unless  a user  application wants  to take  advantage of new
     functions that are only offered in the MNA implementation.

     A major result of the DSA  specific part of this effort will
be that the Multics Organization  will no longer support, or have
control of, one  of the Multics frontends.  This  will impact the
implementation  of many  of the  distributed aspects  of the MNA,
since much  of the support  for distributed services  will not be
implemented by MDC.  That is, changes  to the DN8 will have to be
negotiated  with the  organizations that  support it  (currently,
Distributed  Systems and  Computing Operations,  DS&CO).  It  may
also  have an  impact on  other aspects  of Multics,  such as the
Multics security rating, etc.


     Many  of the  ideas for  the MNA  have been  taken from  the
International   Standards   Organization   (ISO)   Open   Systems
Interconnection (OSI)  Reference Model.  The OSI  Reference Model
is currently a Draft Internation Standard (DIS7498), and is being
extended  with  an  addendum  on  Naming  and  Addressing  and an
addendum on Security.  The rest of this section will describe the
OSI Reference  Model concepts and  terminology.  The rest  of the
MTB will then describe how  the concepts and terminology apply to
the MNA.

5.1 Basic Elements

     There  are four  basic elements  used in  describing the OSI
Reference Model:

   o Systems  - A set  of one or  more computers, the  associated
     software, peripherals, terminals,  human operators, physical
     processes,  information transfer  means, etc.,  that form an
     autonomous   whole   capable   of   performing   information
     processing and/or information transfer.

MTB-748                                Multics Technical Bulletin
                                              Networking Overview

   o Application-Entities  -  An  element  within  a system which
     performs  the   information  processing  for   a  particular

   o Connections  -  The   means  by  which  application-entities
     exchange information.   Although the OSI Reference  Model is
     currently  based  on  the  assumption  that  a connection is
     needed  for   information  transfer,  an  addendum   to  the
     Reference   Model    is   being   developed    to   describe
     connectionless information transfer (e.g.  datagrams).

   o Physical  Media -  The actual  physical connections  between

     The  term  entity  (of  which  an  application-entity  is  a
particular type) is used to refer to that part of a process which
is of concern  to the Reference Model.  That is,  an entity has a
name  and an  address and  is what  uses connections  to exchange
information   with  other   entitites  (see   below  for  further
characteristics of entitites).

5.2 Layers

     Each  system   in  the  Reference  Model   is  divided  into
subsytems,  each  of  which  is  an  element  in  a  hierarchy of
elements, where each element in the hierarchy interacts only with
the elements directly above and  below it.  A particular level in
the hierarchy is called an (N)-subsystem, where N is the level of
the  subsystem in the  hierarchy.  A layer  is the collection  of
subsystems (in  all the systems) which  are at the same  level in
the hierarchy.

     A specific layer is referred to  as an (N)-layer.   The next
higher layer is  the (N+1)-layer and the next lower  layer is the
(N-1)-layer.    An  (N)-entity is   an active  element within  an
(N)-layer and system (i.e.  within an (N)-subsystem).

     Peer-entities are entities within  the same layer.  They may
be on the same or different systems.

     An  (N)-service is  a capability   of an  (N)-layer and  the
layers beneath  it, which is  provided to (N+1)-entitites  at the
boundary   between  the   (N)-layer  and   the  (N+1)-layer.   In
programming terms, a  service is defined by an  interface.   That
is, an (N+1)-entity obtains an  (N)-service by calling through an
interface to an (N)-entity.

     An   (N)-service-access-point   is   the   point   at  which
(N)-services  are provided by  an (N)-entity to  an (N+1)-entity.

Multics Technical Bulletin                                MTB-748
Networking Overview

An (N)-service-access-point is basically identified by an address
as described below.

     An (N)-facility is a part  of an (N)-service.  For instance,
connection   establishment,  data  transfer,   and  disconnection
facilities might be three parts of an (N)-service.

     An (N)-quality-of-service  is a parameter which  expresses a
value  for  some  characteristic  of  a  service.   For instance,
performance   characteristics  like  throughput,   or  connection
establishment   delay,  and   reliability  characteristics   like
residual error rate, or  connection failure probability, might be
possible qualities-of-service for a particular service.

     An  (N)-function   is  a  part  of  the   activities  of  an
(N)-entity.  Generally, (N)-functions are used by (N)-entities to
perform an (N)-service,  but they may also be  used for functions
which are not specifically service oriented (e.g.  "housekeeping"
functions) within an (N)-layer.

     An (N)-protocol  is a set of syntactical  and semantic rules
which  govern the  form and  meaning of  information exchanged by
(N)-entities when performing (N)-functions.  (N)-entities may use
a number of (N)-protocols to perform their functions.

5.3 Names, Titles and Addresses

     A name is a linguistic object which corresponds to an object
in some universe of discourse.   In the OSI Reference Model there
are three basic types of names:

   o A    title   which    names   an    entity,   including   an

   o An address which names a service access point.

   o An identifier  which names something else.   For instance, a
     connection-endpoint,   to   distinguish    it   from   other
     connection-endpoints in a service-access-point (see below).

     Names are assigned by a  naming authority (i.e.  titles by a
title  authority and  addresses by  an addressing  authority).  A
name is expected to be  unambiguous, and to uniquely identify one
object for  all time (or at  least long enough).  One  object may
have  multiple names, or  synonyms.  A primitive  name is a  name
which does not have any  internal structure visible to its users.
A descriptive name is a name  which identifies an object by means
of a set  of assertions concerning the properties  of the object.
Names can also be generic or  multicast.   A generic name names a
set  of objects,  such that  when  the  generic name  is used  to

MTB-748                                Multics Technical Bulletin
                                              Networking Overview

identify  the recipient of  a communication request,  exactly one
member of the set will be selected.  The initiator of the request
has no control over which member  of the set will be selected.  A
multicast name  also names a set  of objects as above,  but, such
that all members of the set will be selected, rather than exactly

     An  (N)-title identifies  an (N)-entity,  and an (N)-address
identifies  an  (N)-service-access-point.   At  a  given point in
time,  an   (N+1)-title  is  bound   to  an  (N)-address   by  an
(N)-directory-service (i.e.   there is a  way to find  an address
for an entity, given its title).  When an (N)-connection is to be
established,  the (N)-layer is  provided with the  (N)-address of
the  desired  destination  (i.e.   (N+1)-entity).   The entity to
address mapping may change over time, but at any given time it is
one to many.  That is, one entity may have many addresses, but an
address can only locate a single entity at a time.

     An     (N)-entity     can     support     a     number    of
(N)-service-access-points  (addresses),  and   use  a  number  of
(N-1)-service-access-points.   This  gives  rise  to  a number of
possible     relations     of     (N)-service-access-points    to
(N-1)-service-access-points through an (N)-entity.  The relations
can  be   one-one,  one-many,  many-one,  or   many-many.   These
possibilities  should not  be confused  with the  multiplexing of
connections as described below.  They  only relate to the ways an
(N)-entity  can  map  the  address(es)  it  provides  to  its own

5.4 Connections

     An  (N)-connection  is  an  association  established  by  an
(N)-layer between two or more  (N+1)-entities for the transfer of
data.   An  (N)-connection-endpoint  is  the  termination  of  an
(N)-connection    within    an    (N)-service-access-point.    An
(N)-service-access-point  may have  many (N)-connection-endpoints
within it at any given time.

     In order to establish an (N)-connection, the local (N)-layer
needs to know the  remote (N)-service-access-point address.  This
is  supplied   by  the  local  (N+1)-entity   which  desires  the
connection.  The  (N)-layer uses this address  to determine:  the
protocol  control   information  to  be  passed   to  the  remote
(N)-entity which "owns"  that (N)-service-access-point; the local
(N-1)-service-access-point    to    use;     and    the    remote
(N-1)-service-access-point   address  to    pass  to   the  local
(N-1)-layer.  The (N)-layer obtains this information by using the
directory funtions mentioned above.

Multics Technical Bulletin                                MTB-748
Networking Overview


     An (N)-entity can map (N)-connections onto (N-1)-connections
either one-one,  many-one (called multiplexing, whose  inverse is
demultiplexing ), or one-many (called splitting, whose inverse is
recombining   ).    These   mappings   are   independent  of  the
service-access-point relations described  above.  Multiplexing is
usually  used  to  make  more  efficient  or  economic  use of an
(N-1)-connection (e.g.  the X25 packet level allows multiple user
connections to share the same physical wire).  Splitting might be
used    to    improve    reliability    (by    having   redundant
(N-1)-connections  for each   (N)-connection), or  provide better
performance  at lower  cost (by  using multiple,  low-cost, slow,
(N-1)-connections to support a single fast (N)-connections).

5.5 Data Units

     (N)-entities exchange data through an (N-1)-connection while
performing  (N)-services for an  (N+1)-entity.  The unit  of data
exchanged    between    two     (N)-entites    is    called    an
(N)-protocol-data-unit.   It consists  of any control information
required by  the protocol and  user data which  has been obtained
from, or is to be delivered to, an (N+1)-entity.

     An  (N+1)-entity  passes  information  to  an (N)-entity for
transfer on an (N)-connection through the interface between them.
The   data   passed   through   the   interface   is   called  an
(N)-interface-data-unit.     It  consists  of  interface  control
information and data to be transferrred on the (N)-connection.  A
very important unit of data available at the interface between an
(N+1)-entity  and an  (N)-entity is  the (N)-service-data-unit.
This is  a unit of  data which is  preserved from one  end of the
(N)-connection  to the  other.  That  is, the  (N)-layer makes an
(N)-service-data-unit  sent  by  an  (N+1)-entity  visible to the
receiving     (N+1)-entity    across    the     interface.     An
(N)-service-data-unit   may   be   contained   entirely   in  one
(N)-interface-data-unit,     or    it    may     span    multiple


     An   (N)-entity  can   combine  (N)-service-data-units   and
protocol  control information  into (N)-protocol-data-units  in a
number  of ways.  It  can combine a  single (N)-service-data-unit
with appropriate protocol control  information to create a single
(N)-protocol-data-unit.    It   can    perform   segmenting   and
reassembling  by  putting   a  single  (N)-service-data-unit  and
appropriate  protocol  control  information  into  more  than one
(N)-protocol-data-unit.  It  can perform blocking  and deblocking

MTB-748                                Multics Technical Bulletin
                                              Networking Overview

by putting  more than one (N)-service-data-unit  with appropriate
protocol      control     information      into     a      single
(N)-protocol-data-unit.     And   finally,    it   can    perform
concatenation   and  separation   by  combining   more  than  one
(N)-protocol-data-unit into a single (N-1)-service-data-unit.  As
the protocol-data-units  at layer N turn  into service-data-units
at  layer N-1,  they must  go through  the interface  between the
layers   as   interface-data-units.    The   boundaries   of  the
interface-data-units are arbitrary with respect to the other data
units, but  the interface must  provide some way  to identify the


     There  are  two  basic  types  of  flow  control:  peer flow
control which regulates the rate at which (N)-protocol-data-units
are sent  between (N)-entities, and interface  flow control which
regulates  the rate  at which  (N)-interface-data-units are  sent
between  and   (N+1)-entity  and  an  (N)-entity.    In  general,
multiplexing will require peer flow control, and the flow control
information will  be part of the protocol  control information in
the (N)-protocol-data-units.

5.6 Routing

     A   routing    function   within   an    (N)-layer   enables
communications between  two or more (N+1)-entities  to be relayed
by  a chain  of (N)-entities.   The fact  that communications are
being routed by intermediate (N)-entities is known by neither the
lower layers nor the higher layers.  Routing specifies how to get
from   a  starting  address   to  a  destination   address.   The
(N)-entities  which participate in  routing require some  sort of
routing table to do their work.


     The MNA  uses the networking ideas described  above to solve
the  prblems  presented  in   Section  3  under  the  constraints
presented  in  Section  4.   The  ultimate  goal  is  to  support
distributed user  applications which implement (and  use) various
services in such  a way that the applications  are independent of
the way in which information is actually trasferred between them.

     For instance, a  user who wants to transfer a  file from his
local  host to  a remote  host usually  does not  care what  file
transfer protocol is used, or  what type of network connection is
used.  Also,  a particular file transfer  protocol implementation
usually  does not depend  on what type  of network connection  is

Multics Technical Bulletin                                MTB-748
Networking Overview

used to get  the protocol information from the local  host to the
remote host.  It only requires that certain services be available
from  the  connection,  for  instance,  that  it  can mark record
boundaries such that  they are visible to the  receiving side, or
that  records are not  lost, and are  received in the  order that
they were sent.

     Later sections of this MTB will discuss the various standard
services   offered  by   the   application   layer  as   well  as
implementation strategies and  interfaces for Network Application
Support  Procedures  (NASPs),  Request  Daemons,  Server Daemons,
Connection  Daemons,  and  Server  Processes  that  handle users'
requests for services.

     The general  networking overview above discussed  layers and
the  services offered by  a layer.  This  is useful in  a general
way, especially  if one then  defines a particular  set of layers
and services (as is done by  ISO).  However, the MNA must support
a  number of  different ways   of dividing  the total  networking
functionality  into  layers  and  services.   Therefore,  the MNA
simply  defines entities  that  provide  services by  using other
services.   These  are  the  same  entities  as  defined  in  the
networking  overview above,  but, by  leaving layers  out of  the
description, they  can be "stacked" in whatever  way is necessary
to meet  the needs of a particular  networking architecture (e.g.
DSA or Internet).

     For  example,  an  entity  which  provides  the Internet TCP
service  would be roughly  the same as  two entities in  DSA, one
which  provided a  session service  by using  a transport service
provided by the other one.  This  still does not provide an exact
match since the TCP service and the session service have a number
of differences.   So, although the Internet services  and the DSA
services  are both  layered, the  layers do  not match  up in any
useful way.

     The  major objects described  by the MNA  systems, entities,
and  services  (as  described  in  the  networking overview), and
addressing endpoints, drivers, and devices.  All of these objects
are described more fully in the following sections.

     Certain  major ideas  have also  been used  in designing the
framework for the implementation of the MNA.

   o All hardware  interfaces will be handled  through IOI.  This
     means that no networking code will run in ring 0.  This also
     dictates  the  use  of  an  Input  Daemon  process  for each
     hardware connection (i.e.  frontend),  because IOI must know
     the  processid  of  a  process  that  will  get wakeups when
     hardware interrupts  occur (and no appropriate  user process
     may exist).  The Input Daemon will use RCP in the normal way

MTB-748                                Multics Technical Bulletin
                                              Networking Overview

     to attach a channel  (frontend) through IOI.  Some unforseen
     circumstances may dictate that  the interface for some piece
     of hardware must bypass IOI.  In this case, some part of the
     networking code would have to run in ring 0.

   o The  Input  Daemons  should  be  timer  driven  rather  than
     interrupt  driven,  if  at   all  possible  (e.g.   the  DN8
     interface  (CXI)  is  timer  driven).   We  hope  this  will
     ameliorate possible  performance problems which  might arise
     from handling  interrupts in ring  1 rather than  ring 0 (as
     MCS currently does).

   o Output  should be  handled in   the user's  process with  as
     little  copying as  possible.  In  general, the  user's data
     should be  copied (once) from  the user's buffer  to the IOI
     workspace of the channel which  will send it out of Multics.
     Input should be  handled by the Input Daemon  and the user's
     process with  as little copying  as possible.  This  is even
     more  important than  the  output  copying, since  the Input
     Daemon  can easily  become a  bottleneck if  it has  to copy
     large amounts  of user data  (because taking page  faults is
     expensive).  This should be done  by leaving the data in the
     IOI  workspace  when  it  arrives,  and  letting  the user's
     process copy it to its eventual destination.

   o An  entity which provides  a many-one, or  many-many mapping
     for service access points, or which provides multiplexing of
     connections, must  run in ring 1 because  it can potentially
     handle data for different users simultaneously.  Notice that
     one-many  mappings for  service access  points, or splitting
     for  connections, do  not generate  this requirement.   This
     also means that most Input Daemons  must run in ring 1 since
     they will be handling connections for multiple users through
     a  single  hardware  channel.   If  the  hardware channel is
     dedicated to a single user at  a time, then the Input Daemon
     does not need to run in ring 1.


     In  the MNA, a  system is identified  by a descriptive  name
which consists of a primitive  name for the system, together with
a hierarchy  of primitive names  of the naming  domains needed to
make the primitive name of the system unique.  The syntax is that
used for Internet domain names, for example, "CISL.HONEYWELL.COR"
might name  the CISL machine.  The primitive  names that identify
naming  authorities will  be the  names defined  by the  Internet
authorities,  and  the  naming  authorities  are  assumed  to  be
hierarchically arranged, as specified in RFC-882 and RFC-883 (see
>udd>m>gmp>doc>mail>  Systems are defined in the
Network Information Table (the NIT).

Multics Technical Bulletin                                MTB-748
Networking Overview


     An (N)-entity provides an  (N)-service to an (N+1)-entity by
using the services offered by (N-1)-entities.  The (N)-service is
provided  at an (N)-service-access-point  which is located  by an
(N)-address.   An  (N)-entity  uses  a  set  of  (N)-protocols to
provide the (N)-service.  For example, an entity which provides a
file transfer  service might use the DSA  file transfer protocol,
or the Internet file transfer  protocol, depending which parts of
the   file  transfer   service  (i.e.    which  facilities)  were
requested.  For  instance, if checkpointing of  the file transfer
was  requested,  the  entity  would  use  the  DSA  file transfer
protocol, since it supports  checkpointing, and the Internet file
transfer protocol does not.

     An entity has  a title which is a 3-tuple  consisting of the
name of the  system on which the entity resides,  the name of the
service offered by the entity,  and an identifier which makes the
3-tuple unique in case there is  more than one entity on a system
offering the same service.  Entities  are defined in the NIT, and
the syntax for their names will be described in a future MTB.

     A  particular layering  of  entities  always has  a top-most
entity called the application enitity.   It does not have service
access points, or define addresses in the MNA sense.  Instead, it
offers a service directly to a user.

     The rest of the entities in a particular layering are called
networking entites.   These entities  also have a top-most entity
called  (surprise!)  the top-most  networking entity.    Also, at
some point in a particular layering,  the next entity will not be
implemented on Multics, but will  be implemented in some exterior
piece of  hardware connected to  Multics through an  IOM channel.
The interface to that exterior entity  is provided by a driver on
Multics.   A driver  may need  to provide  a number  of different
interfaces if the exterior hardware and software is sophisticated
enough to implement  a number of different types  of entities.  A
driver  is a  program that   handles both  input and  output, and
generally runs  in both an  Input Daemon process  (see below) and
the  users'  processes.   A  driver  uses  a  device which is the
connection  to  the  exterior   hardware.   The  connection  will
normally  be an  IOM channel,  but could  be an  MCS channel.  An
Input  Daemon  will  be  responsible  for  one  or  more devices.
Drivers and devices are defined in the NIT.

     The  decision as to  where to make  the division between  an
application  entity and  the top-most  metworking entity  is made
using the  following criteria.  In  the NIT, a  networking entity
has addressing information assoicated with it, and an application
entity does  not.  An application entity does  not provide either
multiplexing of  connections, or a many-one  service access point

MTB-748                                Multics Technical Bulletin
                                              Networking Overview

mapping.   The top-most  networking entity  has at  least one  of
these features.


     The pair consisting of a top-most networking entity name and
an  address (of a  service access point)  is called a  networking
endpoint.   This is the address  of an application entity, and is
also  the  point  at  which  networking  security  information is
attached.   The  top-most  networking  entity  is responsible for
using this security information as described in later sections.


     A  service  provided  by  an  entity  is  a  related  set of
facilities with a defined interface.  A service also has a set of
associated qualities-of-service  which can be requested  when the
service is  invoked.  The purpose  of defining a  service and its
interface is  to hide the  details of the  implementation of that
service.  The implementation of a service will use a set of lower
level services.

10.1 How Does a Service Look to Its User?

     A  service has a  name and is  implemented by a  program (or
gate) with a specific set of entries.  The entries will generally
correspond to particular facilities of the service, and arguments
to the entries will  specify quality-of-service parameters, along
with  other  information  required  to  invoke  the facility.  An
entity is just an invocation  of the program that implements that
entity's service.   If the program which implements  a service is
written so that each invocation  maintains its own data (e.g.  an
address space or a state table)separately from other invocations,
then there  can be multiple  entities offering that  service.  In
this  case, the  identifier part  of an  entity name  is just the
information that  the program needs to locate  the particular set
of data for that entity.

10.2 Standard Application Entity Services

     The following standard application entity services have been
identified   (i.e.    they   will   have   command   interfaces):
file_transfer,  remote_login, and  mail.  The  command interfaces
for the file_transfer and  remote_login services will be provided
using  the standard  NASP interface  (see MTB-NCI).   The command
interface for the mail service will be the standard mail commands
(read_mail, send_mail, etc.).

Multics Technical Bulletin                                MTB-748
Networking Overview

     Each of these application entities  will use the services of
various top-most  networking entites (e.g.  DSA  session control,
or TCP).  The  intent is that these application  entities will be
able  to  use  any  top-most  networking  entity  that provides a
certain  minimum  set  of  facilities.   For  instance,  the file
transfer entity  might provide get_file and  put_file facilities,
and require connect, disconnect,  read, and write facilities from
a  top-most   networking  entity.   The  program   providing  the
file_transfer service would be structured  in such a way that the
different  protocols that  might be  used for  file transfer  all
provide  the get_file  and put_file  facilities by  making use of
these top-most networking entity facilities.

     The mail  service should use a  "reliable transfer" service,
which  would  provide  reliable,  store  and  forward transfer of
arbitrarily  sized blocks  of data   from host  to host  (through
multiple  networks if  necessary, and  with no  direct connection
between the  source and destination hosts  needed).  This service
is not currently defined, but will be discussed in a future MTB.

10.3 Networking Entity Services

     As  part of  the Multics  DSA project  a DSA_session service
will   be  provided   by   a   top-most  networking   entity.   A
DSA_transport service will  also be provided by a  driver using a
device  corresponding to an  IOM DIA channel  connected to a  DN8
frontend.   The driver  will  use  the Common  Exchange Interface
(CXI)  to  talk  to  the  entity  in  the  DN8  which handles DSA
transport  control.  Future  top-level networking  entities might
provide  an Internet_TCP service  and an X25_level_3  service.  A
networking entity might also provide an Internet_IP service.  The
names  of these  services are  for illustration  only, the actual
names would be defined in the NIT for a particular system.


     The MNA must address security issues in much the same way as
these issues  are currently addressed  in Multics.  That  is, AIM
support  must be designed  into all the  inner ring software  and
databases (e.g.  the NIT, the  Input Daemons, etc.).  The current
networks  to which Multics  is connected (e.g.   TYMNET, TELENET,
etc.)  are insecure, and this is  likely to remain true of future
network connections.   Thus, the MNA must provide  the same level
of  security as  is provided   on current  networks, and  also be
flexible enough  to use the  features of secure  networks if they
exist.   The problem in  the MNA is  compounded by the  fact that
many  frontends (e.g.  the  DN8) can no  longer be assumed  to be
secure.   In MCS, security  is provided by  the isolation of  the
frontend from users, and its  complete control by the secure part

MTB-748                                Multics Technical Bulletin
                                              Networking Overview

of the Multics operating system.  In the MNA, the frontend can no
longer  be  assumed  to  be  isolated.   For  instance,  on a DSA
network, the DN8  frontend is accessed directly by  users as they
provide  the  information  needed  to  connect  their terminal to
Multics (or any other host in the DSA network).

     Handling  security for server  daemons presents a  number of
problems.   Remote users must  identify themselves to  the server
daemon, probably by presenting a user id and password.  Since the
remote user's request may have been sitting in an insecure remote
host  queue for  some time,  the user  may not  want to  have the
password that he uses for the server be the same one that he uses
to  login to  Multics (which  is presumably  more immediate,  and
therefore, more secure).  Thus, we might  want to use the idea of
a "high  security" password and  a "low security"  password.  The
high security password  would give rise to a process  in the same
way as is  currently done.  The low security  password would only
allow a process to be created in ring 6 or ring 7.  It would also
restrict   some   of   the    login   control   arguments,   e.g.
-change_password.   We  would  then  have  to  make the necessary
changes to the system to allow support for ring 6 or 7 processes,
and to make it easy for  users to make use of their discretionary
access  control without a  lot of work  (e.g.  not having  to use
set_acl and  set_ring_brackets all the  time to get  some desired

     Server  Daemons must  also be  able to  handle requests from
remote users who are not registered on the local system both with
respect to security, and with respect to billing for services.

     One  way to avoid  some of the  security problems of  Server
Daemons is to usee a Connection Daemon to create a Server Process
(see below).  This process is just a standard user process with a
special   process  overseer,   thus  avoiding   the  problems  of
interpretive access control, billing, etc.

     Security in the MNA will be enforced by the top-most network
entities at  the networking endpoints.  Each  networking endpoint
will be  an object in a  security database, with an  extended ACL
attached  to  it  to  control   access  to  that  endpoint.   The
networking endpoint names consist of a top-most networking entity
name, and an address.  "Star"  name components will be allowed as
a  shorthand notation.   As examples,   the endpoints  for a  DSA
session entity are (session  control entity name, mailbox) pairs;
in the Internet,  they are (TCP or UDP entity  name, port number)
pairs; and in an X25 network,  they are (X25 level 3 entity name,
subaddress) pairs.  The  current plan is to allow  both local and
remote  endpoints into  the database,  and check  a local  user's
access to  the local endpoint and  to the remote endpoint  when a
connection is requested,  and to check a remote  user's access to
the  local endpoint for  incoming connections.  The  extended ACL

Multics Technical Bulletin                                MTB-748
Networking Overview

modes allowed are:

      l - listen for incoming connections allowed
      c - calls (outbound connects) allowed
      r - remote use (inbound connects) allowed

     Networking endpoints are  created by network administrators,
since  this may  involve changes  in  the  NIT as  well as  other
changes that normal users should not be allowed to do.

     This design,  and the acutal structures  and algorithms used
in the security database, are discussed more fully in MTB-SEC.


     Most  of  the   information  describing  systems,  services,
protocols,   entities,  etc.,  will   be  kept  in   the  Network
Information Table  (NIT).  The information in this  table will be
used by all parts of the MNA.   It will be possible to update the
information  dynamically by   using an  administrative subsystem.
Most of  the information should  be fairly static,  although some
information may change more frequently.

     In the context  of RFCs 881, 882, and  883 referenced above,
the NIT is the repository for the authoritative information about
a particular part of the  domain name space.  This information is
used to  build the database  to which queries  are directed.  The
user interface to  this information is through a  resolver.   The
resolver  accesses the  local  database  and queries  remote name
servers if necessary, perhaps updating  the local database in the
process.  The local database will also be used by any name server
on Multics.  The resolver cooperates  with the local name servers
in maintaining this database.

     Details of  the design of  the NIT, the  local database, the
standard subroutine (i.e.  resolver  and name server) interfaces,
and the  administrative interfaces will be specified  in a future


     As a  networking connection is established  through a number
of entities, each entity will need to keep some information about
the connection.  Each entity will  also need some way to identify
this information in a process independent fashion, since the code
for a  particular entity may run  in more than one  process (e.g.
an  Input   Daemon  and  a  user  process).    Pointers  are  not
sufficient,  since multiple  processes  will  have to  access the
information.  In order to make this job easier, a standard set of

MTB-748                                Multics Technical Bulletin
                                              Networking Overview

subroutine  entries will  be defined  that will  create an object
with  a standard  header, and  an arbitrary  user specified  data
area.  These  entries will create  and use a  process independent
"handle" to  find the object.  The  objects will be created  in a
known  place, and  will be  linked together  through the standard
header to  facilitate administrative operations (such  as cleanup
on process destruction).


     In  general,  a  particular  IOI  connection  will be shared
between  all of  the users  who have  connections which  use that
physical connection (either a DIA,  PSIA, or CPI channel), and an
Input  Daemon.  The  Input Daemon  is the  only process  which is
guaranteed to exist and know about the IOI connection.  It is the
process  which initially  attaches the  channel through  RCP, and
therefore, is  known to IOI.  It  is also the process  which will
initially  process all  input on  that connection  and handle all
hardware interrupts.

     The  Input Daemon  runs  the  driver software  which handles
whatever protocol is used between Multics and the external box at
the other  end of the channel  (the driver software also  runs in
the users' processes for output).  For instance, for DSA with the
DN8 frontend, the  Input Daemon will run a timer  which causes it
to  wake up periodically  to check an  input queue for  input, as
specified  by the  CXI.  For  the Hyperchannel,  the Input Daemon
would be the process which would get the interrupts from the PSIA
channel,  and  then  distribute  them  to  the  user processes if
necessary.  It should be possible  to have multiple Input Daemons
for  a connection, but  the details of  how this would  work will
require further study.

     The Input Daemon  will handle input by running  the code for
each entity up to the  top-most networking entity.  Each protocol
implementation used by  an entity will have to  maintain a shared
database to coordinate the protocol between the input side of the
protocol in the Input Daemon and  the output side of the protocol
in   the  user's   process.   The   top-most  networking   entity
implementation  should allow  ipc_ wakeups  to be  sent from  the
Input Daemon to the user's process  for normal input.  A new ips_
signal will be  defined for the MNA which can  optionally be sent
in exceptional cases.  The user should be able to specify whether
either  of these  types of  wakeups will  be sent,  or whether he
should simply receive an error code the next time he makes a call
to  the  top-most  networking  entity  (e.g.   the  way  MCS uses

     Input  from the  physical channel  will first  appear in the
wired IOI workspace belonging to an Input Daemon.  The networking

Multics Technical Bulletin                                MTB-748
Networking Overview

entity  implementations should leave  the input in  the workspace
until  it can  be copied  out  by  the user  process to  which it

     Output  will  generally  be  handled  directly  by  a user's
process  in  an  inner  ring,  with  no  intervention by a daemon
process necessary.  This will be  done by having the user process
know the pathname  of the wired IOI workspace, and  being able to
copy output  data directly into  it.  This does  not preclude any
particular implementation which requires  a daemon to handle both
input and output across the physical channel.  However, this type
of implementation should only  be necessary in exceptional cases,
since the daemon can easily become a bottleneck.

14.1 Timers

     A  number of  protocols that  might be  run by  entities use
timers in their operation.  For instance, a timer might control a
timeout for  re-transmission of data, or  the time to wait  for a
connection  request to  be acknowledged.   The normal  way to run
these timers would be by  using timer_manager_ alarm call timers.
However, since many of the  networking entities may be running in
ring 1 (not the user's normal login ring), this approach will not
work.   Thus, these timers  should probably be  run in the  Input
Daemons.  If all of the  networking entities running in the Input
Daemon run in ring 1  then timer_manager_ alarm call timers could
be used.   Alternatively, the hardware interface  code (a driver)
running  in the  Input Daemon  could provide  a timer  management
service.  For instance, CXI is  timer driven, itself, so it could
maintain a list  of timers for the networking  entities, which it
would check each time it woke  up.  In any case, the entries that
are called by  an alarm call must be very  carefully written, and
run with alarms inhibited, so  that other timers going off cannot
generate inconsistent states.


     A number of types of  daemons and special user processes are
described below.  We expect most of the daemons to use tasking to
make it  easier to implement multiple activities  in each daemon.
More details on these can be found in MTB-NSA.

15.1 Request Daemons

     A request daemon is a process that has been set up to handle
the requests in  a request queue or set of  queues.  The requests
are built by  NASP entries, and are put in  the queue by standard
system software.  Request Daemons  will manage the request queues

MTB-748                                Multics Technical Bulletin
                                              Networking Overview

themselves, without the help of  a coordinator daemon (i.e.  like
the  IO  coordinator).   This  will  require  new message segment
primitives to allow individual entries in a message segment to be
locked and updated in place.

15.2 Server Daemons

     A server daemon is a process that has been set up to provide
a service over  a network.  For instance, a  file transfer server
daemon might  be set up  to handle remote  file transfer requests
from the Internet.  A server  daemon does the processing for each
request itself, using some  form of "interpretive" access control
to provide service to different users.

15.3 Connection Daemons

     In order to avoid changing the Answering Service each time a
new network or terminal handling protocol is added, there will be
a set of  connection daemons to handle the  initial dialogue with
users trying  to login or  request services.  These  daemons will
have  to  be  trusted  because   they  will  be  handling  users'
passwords.   The  daemons  will  engage  in  whatever dialogue is
appropriate with  a user and obtain the  information necessary to
create a process.   For instance, on some DSA  networks, the user
must login to the DN8  and provide name, password, authorization,
etc.  If the user then connects to Multics, the DN8 packages this
information into  a security record  and sends it  along with the
connection  request.  The  connection daemon  in this  case could
just  use this information  without further interaction  with the

     Once  the   connection  daemon  has  gotten   the  necessary
information,  it will  engage in  a dialogue  with the  Answering
Service to  create a process.   This dialogue will  be carried on
through  a message  segment, and  will follow  a strict  protocol
using defined record structures to hold the information.

     The  connection daemon  will be  the "owner"  of the network
connection, and will have a way to make the newly created process
the  "user" of  the connection.    The AS  will notify  the login
daemon  when a  process, which   has a  connection for  which the
daemon is the  owner, is terminated in order that  the daemon can
make sure the connection is properly terminated.

15.4 Server Processes

     A  server processes is  a normal user  process created by  a
connection daemon with a  special process overseer.  This process

Multics Technical Bulletin                                MTB-748
Networking Overview

overseer performs the requested application entity service on the
connection and then logs out.  The current Internet file transfer
application  works in  this way,  as does  the Satellite  6M file


     A new terminal interface has not yet been designed.  For the
DSA implementation  details, see MTB-DSATM.  Basically,  calls to
TM will replace calls to hcs_  in tc_io_ (the lowest layer of the
video  system).  An IOX  interface for TM  will also be  written,
similar  to window_io_iox_,  for use  by processes  not using the
video system.


     Network  administration in  the MNA  will be  concerned with
many  of the  same things  that current  MCS administration deals
with:  logging interesting events, loading and dumping frontends,
adding and deleting networks and hosts, setting access to network
connections, turning  tracing and debugging features  on and off,
etc.  Each of these is discussed below.

17.1 The Network Log

     The network  log will use  the new logging  technology being
developed for  security purposes.  The major events  to be logged
are  the  creation  and  destruction  of  the  connection objects
described  above.   All   administrative  modifications  will  be
logged.   Each  entity  implementation  will  have  some  set  of
"interesting"  events  that  it  will  log  during its operation.
Standard tools will be available  for printing and displaying the
log, and  each entity implementation  will have entries  that can
interpret its "interesting" log entries.

17.2 Loading and Dumping Frontends

     There will  be standard administrative commands  to load and
dump  frontends.  Each type  of physical connection,  and channel
protocol, will have code which implements these standard actions.
For  instance, for  the DN8  connected across  a DIA,  there is a
Cross-Net Protocol  (CNP) used to  transfer DN8 core  images from
the host  for loading, or to  transfer dumps from the  DN8 to the

MTB-748                                Multics Technical Bulletin
                                              Networking Overview

17.3 Metering

     Each  entity  implementation  will   keep  meters  that  are
appropriate for  what the entity  does.  For instance,  counts of
bytes sent and received, counts  of packets or frames, etc.  Each
entity will also provide  interfaces for retrieving and resetting
these  meters.   In  addition,  the  "interesting"  events in the
network log may contain metering information.

17.4 Debugging and Tracing

     Each  entity implementation  will have  standard entries for
tracing its operation.  It  will also have non-standard debugging
entries for use by systems personnel.


     Any network  or hardware specific T&Ds used  by the Customer
Services Division (CSD) in supporting customers will be supported
by each entity and frontend implementation.


     Frontend  specific tools  will  be  provided to  analyze the
dumps generated by  a frontend.  In the case of  the DN8, we hope
to re-host tools that have been developed to run on DPS 8 and DPS

17.5 Config Deck Changes

     The  Multics  config  deck  will  be  modified  to allow the
definition of frontends, so that RCP and IOI can handle them like
any other piece of hardware described in the config deck.


     This index lists all of the  terms defined in this MTB along
with the page number on which they were defined.


"(N)-address" 6                   "Application-Entities" 4

"(N)-connection" 6                "blocking" 7

"(N)-connection-endpoint" 6       "concatenation" 8

"(N)-directory-service" 6         "connection daemon" 18

"(N)-entity" 4                    "connection" 4

"(N)-facility" 5                  "deblocking" 7

"(N)-function" 5                  "demultiplexing" 7

"(N)-interface-data-unit" 7       "descriptive name" 5

"(N)-layer" 4                     "device" 11

"(N)-protocol" 5, 11              "driver" 11

"(N)-protocol-data-unit" 7        "entity" 4

"(N)-quality-of-service 5         "generic" 5

"(N)-service" 4                   "identifier" 5

"(N)-service-access-point" 4      "input daemon" 16

"(N)-service-data-unit" 7         "interface" 4

"(N)-subsystem" 4                 "layer" 4

"(N)-title" 6                     "multicast" 5

"(N+1)-layer" 4                   "multiplexing" 7

"(N-1)-layer" 4                   "name server" 15

"address" 5                       "name" 5

"application enitity" 11          "networking endpoint" 12

"networking entites" 11           "separation" 8

"peer-entities" 4                 "server daemon" 18

"physical media" 4                "server processe" 18

"primitive name" 5                "splitting" 7

"reassembling" 7                  "subsytems" 4

"recombining" 7                   "Systems" 3

"request daemon" 17               "title" 5

"resolver" 15                     "top-most networking entity" 11

"segmenting" 7                    NIT 15