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
1 ABSTRACT
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
MTBs.
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
2 INTRODUCTION
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
overhead."
3 WHY WE NEED NEW NETWORKING SUPPORT
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
maintain.
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
channels.
4 WHAT WE ARE TRYING TO DO
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.
case).
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.
5 SOME NETWORKING IDEAS AND TERMINOLOGY
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
application.
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
systems.
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
application-entity.
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
one.
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
address(es).
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
5.4.1 MULTIPLEXING AND SPLITTING
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
(N)-interface-data-units.
5.5.1 RELATIONSHIPS BETWEEN DATA UNITS
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
service-data-units.
5.5.2 FLOW CONTROL
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.
6 MULTICS NETWORKING ARCHITECTURE (MNA) OVERVIEW
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.
7 SYSTEMS
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>DDN.domains.doc). Systems are defined in the
Network Information Table (the NIT).
Multics Technical Bulletin MTB-748
Networking Overview
8 ENTITIES, DRIVERS, AND DEVICES
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.
9 NETWORKING ENDPOINTS
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.
10 SERVICES
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.
11 SECURITY
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
effect).
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.
12 THE NETWORK INFORMATION TABLE (NIT)
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
MTB.
13 THE CONNECTION OBJECT MANAGER SOFTWARE
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).
14 THE INPUT DAEMONS
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
error_table_$line_status_pending).
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
belongs.
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.
15 HANDLING USER REQUESTS -- DAEMONS AND SPECIAL PROCESSES
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
user.
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
transfer.
16 NEW TERMINAL INTERFACE
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.
17 NETWORK ADMINISTRATION
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
host.
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.
17.4.1 TESTS AND DIAGNOSTICS (T&DS)
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.
17.4.2 DUMP ANALYSIS
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
6.
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.
18 INDEX OF TERMS
This index lists all of the terms defined in this MTB along
with the page number on which they were defined.
INDEX
"(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