IEN 32
Section 2.3.3.12

Title: Catenet Monitoring and Control: A Model for the Gateway Component

Author: John Davidson  [Davidson@BBNE]

Note: This document contains figures which are not included in this on line
version, the figures may be obtained in hardcopy from the author.


                 CATENET MONITORING AND CONTROL:

                A MODEL FOR THE GATEWAY COMPONENT

                          John Davidson

                  Bolt Beranek and Newman, Inc.

                             IEN #32

               Internet Notebook Section 2.3.3.12

                         April 28, 1978

                 Catenet Monitoring and Control:

                A Model for the Gateway Component





1.  INTRODUCTION


     At the last Internet meeting,  some  concern  was  expressed

that  we don't have a real "model" for what a gateway is, what it

does, and how it does it, and that without such  a  model  it  is

somewhat  dificult  to  describe  the  kinds  of activities which

should be monitored or controlled by  a  Gateway  Monitoring  and

Control  Center  (GMCC).   To  respond  to  that concern, we have

written this note to express our recent thoughts about a  gateway

model.  Although the note centers primarily around the topic of a

gateway  model,  we  have  also  included  a  few  thoughts about

possible  models  for  the  other   components   of   a   general

internetwork structure.

     The  note  proceeds  as  follows.   In  Section  2 we try to

establish a reason for wanting a model of  a  given  internetwork

component, and present a brief overview of the potential benefits

of   Monitoring   and  Control.   This  presentation  is  largely

pedagogical since it is assumed that this document  will,  for  a

while  at least, be the only introduction to the topic available.

     In Section 3 we discuss the fundamental kinds of  activities

which  must  be  performed  by any internet component if it is to

participate in Monitoring and Control.  This section  establishes

motivation  for  some  of the mechanisms discussed in the rest of

the paper.

                              - 1 -

     In Section 4 we discuss the roles  which  the  hosts,  local

Packet  Switching Networks (PSNs), and the Gateway Monitoring and

Control Centers (GMCCs)  may  have  to  play  in  Monitoring  and

Control for the internet.

     Then,  in  Section  5,  we  finally  begin  to  discuss  the

principle  characteristics  of  a  possible  gateway  model.   We

examine first a list of practical constraints which influence the

way  in  which  the  model  is being designed, and then, suitably

constrained, we begin the task of developing the model itself.  A

complete modelling has not yet been performed, and is  likely  to

take  quite  a  while  to  complete.  Section 5, however, gives a

suitable indication of  the  way  in  which  the  model  will  be

developed,  and  of  the alternative interpretations available to

gateway designers who pattern  their  implementations  after  the

model.


























                              - 2 -

2.  CONTEXT F OR MODELING

     It  is  assumed  that  gateways  exist to make communication

possible between hosts on different packet switching networks. In

this regard, they actually serve to make a single network out  of

several diverse, disjoint networks.  Thus gateways can be said to

form  the  nodes  of  a  super-network,  called  a Catenet, whose

"links" are the individual packet switching networks,  and  whose

"hosts"  are simply the individual hosts of the constituent PSNs.

As the nodes of this super-net, the gateways will be  responsible

in  part  or in whole for tasks like routing, fragmentation, flow

control,   reassembly,   retransmission,   and    perhaps    data

transformation  (e.g. encryption/decryption), access control, and

even authentication.

     We can assume that there are benefits  to  be  derived  from

having  the  Catenet  operate in a coordinated fashion.  However,

coordination is not achieved by default, because the  Catenet  is

being  constructed  in  pieces, with each piece potentially under

the control of a distinct administrator, each gateway implemented

in a unique processor, and each program conforming to a different

programmer's view of the workings of a gateway.


     The  Internetworking  group  brought  together  by  ARPA  is

serving as the coordinating authority for the development of many

of  the  components  of  the  Catenet.   To  make  the  important

administrative and technical decisions  associated  with  Catenet

construction, however, this group must be provided with technical

inputs.   Many of these inputs can come from theoretical studies,



                              - 3 -

protocol  investigations,   and   pre-construction   experiments,

modeling,  and  simulation  during  Catenet development.  But the

most important source of technical inputs will ultimately be  the

Catenet  itself.   If the true operational characteristics of the

net  can  be  readily  (and  continually)  determined,  then  the

administrative   issues   associated   with  Catenet  performance

(questions like "why is the throughput not as  predicted",  "what

components  are  proving unreliable", "should the net be expanded

or reconfigured", etc) can be adequately resolved  by  appeal  to

the  recorded  statistics;   collection  and  recording  of these

operational statistics form a part of what we refer to as Catenet

"Monitoring".  Also, since the  Catenet  will  sometimes  be  the

"target"  of  the  Internet  group or ARPA administrative policy,

then, insofar as policy affects the operation of  the  net  (e.g.

such  "policy"  decisions as "failed components should be dumped,

reloaded, and restarted ASAP"), technical tools must be  provided

which  help  implement  the  policy;  these kinds of tools form a

part of what we refer to as Catenet "Control".  (Some readers may

prefer to think of this as "Coordination" rather  than  "Control"

which unfortunately may carry other undesirable connotations.)

     In  order to be able to Monitor and Control the operation of

the Catenet in accordance  with  administrative  policy,  in  the

presence of the diverse component implementations, some model for

the  network  as a whole should be developed.  Futher, models for

each of the component types  (gateways,  packet  switching  nets,

hosts)  should  be developed.  These model implementations should

then  be  instrumented  in  a  way  that  makes  it  possible  to


                              - 4 -

accumulate  the  technical  inputs  and to effect the operational

policy  desired  by  Catenet  administrators.    If   the   model

implementations  are appropriately general, then it is reasonable

to dictate that individual implementations adhere to these  basic

models.


     BBN is currently pursuing the development of a model for the

gateway  component  of the Catenet.  In particular, we are trying

to define how the model should be  instrumented  to  provide  the

appropriate  kinds  of Monitoring and Control capabilities.  Most

of the capabilities we think are needed are similar  in  function

to  the  capabilities  already  developed for the ARPANET and its

Network Control Center, NCC.  We are proposing, and in fact  have

actually  begun,  the  construction  of  a Gateway Monitoring and

Control Center (GMCC) patterned  after  the  NCC  (and  currently

sharing resources with it, since the NCC is already accessible to

internetwork  traffic  and since the scope of the current GMCC is

at this time quite modest).





















                              - 5 -

3.  FUNDAMENTALS OF MONITORING AND CONTROL

     We assert that all of  the   Catenet  components  should  be

properly instrumented in software (and if necessary, in hardware)

to measure the service which the Catenet as a whole provides, and

to  enhance  the  maintainability  of  the  net  as a whole.  The

instrumentation  should  provide  us  with  all  the   mechanisms

required to perform


          Performance Monitoring


          Event Recording


          Functional Testing


          Component Maintenance



Here,  by  Performance  Monitoring,  we intend that the status of           _______________________

Catenet  components  (both   the   binary   "working/not-working"

indication  and the status of internal operational components) be

made available to the GMCC.  This will require that  the  Catenet

components  have  a  mechanism  for communicating periodic status

reports and instantaneous error reports "back" to the GMCC.  This

mechanism may or may  not  require  that  the  reports  from  the

various  net  components  be  synchronized in order to enable the

GMCC to obtain a  "snapshot"  of  the  network  as  a  whole;  if

synchronization  is  required,  a synchronizing mechanism will be

required as well.  It is also undetermined  whether  a  protected

path (e.g. one using encryption to prevent spoofing)  is required

for communicating this information through the Catenet.


                              - 6 -

     There  should  also  be  a  mechanism  by which the GMCC can

request performance data from a Catenet component in the case  of

non-recurring  measurements.   The  set  of monitoring mechanisms

installed in any particular component may  differ  from  the  set

installed in any other component, depending on the granularity of

measurement which is desired in each case.

     By  Event Recording, we intend that the raw statistical data         _______________

on, say, the number of messages  or  packets  passing  through  a

given  component be made available to the GMCC in a standard way.

Not only must there be a standard way  of  collecting  the  event

statistics,  but  there  must  also  be  a  way  for a designated

authority like the GMCC to reset the event counters, say, or turn

on or off the event recording mechanisms. We shall have  more  to

say on what events are significant in a subsequent section.

     By  Functional  Testing  we  intend that the GMCC be able to         ___________________

direct the activities of the Catenet components  either  directly

(by  commanding performance of some task like message generation)

or indirectly (by sending, or directing other components to send,

messages  through  a  given  component)  in  order  to   exercise

component  mechanisms  for  error  analysis  or  load testing.  A

useful mechanism in the ARPANET is the ability to isolate  failed

hardware  components by forcing a loopback under software control

at each of the component boundaries.  The analogue of this scheme

in the Catenet is probably  simpler,  since  the  boundaries  are

logically  in  software  (e.g.  in  the gateway software in cases

where a local PSN or another nearby gateway is being  tested)  or

associated  with the local PSN which may have reasonably flexible


                              - 7 -

control of the interface which connects it to a network  host  or

to  a  gateway.  Looping performed within a component should also

be possible.

     To make use of these testing facilities, we need the ability

to generate artificial traffic (and to discard it) and to reflect

it (or turn it  around)  as  required.   Reflecting  messages  at

gateways  can,  for  example, give a measure of the throughput of

Catenet links.


     By Component Maintenance, we intend that the GMCC  have  the        _____________________

ability to coordinate, and in some cases perform, the analysis of

failure   for   failed  components,  the  restoration  of  failed

components,  the  institution   of   program   fixes,   and   the

distribution  of  new  releases.   It is not clear that Component

Maintenance can be the responsibility of just a single  GMCC,  of

course,  but  if  it is to be the responsibility of any GMCC-like

component, then the mechanisms by which the failed  component  is

to  be  handled,  and  how  it is to be of use in the maintenance

activity, should be adequately modelled  for  each  component  in

question.    In   this  regard,  we  see  a  potential  need  for

incorporating mechanisms for  self  diagnosis  in  the  component

models,  for  enabling  the  GMCC  (or some other network host in

conjunction with or in place of  the  GMCC)  to  read  and  write

arbitrary locations in a component's memory, etc.

     Note  too  that  the  gateway  programs  will be provided by

various implementers.  These implementers may in  some  cases  be

willing  to  allow a given GMCC to handle reloads and restarts of



                              - 8 -

their component when it fails.  Both the implementer and the GMCC

staff may have to be involved in debugging the component  if  the

gateway's  model  debugging facility (which presumes the use of a

GMCC) is all the original implementers have for  accessing  their

component  remotely.   It  might  prove useful for the GMCC to be

able to copy the contents of a failed component into a  file  for

later  inspection  by  the original implementers in case they are

unavailable to copy  the  contents  themselves  at  the  time  of

malfunction.






































                              - 9 -

4.  MODELS FOR THE PRINCIPLE CATENET COMPONENTS


     This  note is principally about gateway modelling.  However,

we  have  asserted  throughout,  the  need  to  model  the  other

components  of  the  general  Catenet as well, so that we can use

them in Monitoring and Control applications where they are needed

and where they can be useful.  Here we describe briefly the goals

we have for modelling the other components.


4.1  The GMCC

     The functions of a GMCC should be able to  be  performed  by

any  host  in  the  composite net.  In view of this, a high level

description, or model, of the  way  a  GMCC  operates  should  be

created.  Both the GMCC program(s) and its data base(s) should be

described  in  a  way which allows Catenet users to reproduce the

GMCC functions  (this  basically  requires  coding  of  the  GMCC

programs  in  a  high  order  language)  and  to  interrogate  or

duplicate the accumulated data base(s) as required for their  own

special purposes.

     Because  each  gateway,  host, or local PSN component of the

composite Catenet is  potentially  the  property  of  a  distinct

administrative  authority,  it  is  conceivable  that  each might

actually be monitored or controlled by  a  distinct  GMCC.   This

would  not  necessarily  be  the best arrangement for purposes of

overall net maintainability, but nonetheless must be allowed for.

What is more likely, however, is that a given administrator  will

give  permission  to  some  approved  Catenet GMCC to perform the

Monitoring and Control  activities  associated  with  Performance


                             - 10 -

Monitoring,  say, or with Event Recording, but reserve for itself

the ability to perform the activities associated with  Functional

Testing   and   Component   Maintenance.    In   this  case,  the

Administrator's host will have  to  understand  and  be  able  to

duplicate  the  model  GMCC  functions, and the Catenet component

will have to know to respond to one or the other  GMCC  depending

on  the  function  being  requested.  Since different authorities

might exist for each different function, this  capability  should

be  modelled.  Further,  the  mechanism  for changing the name or

address of the various  designated  authorities  should  also  be

modelled.   Then  the  fact that each Catenet component knows the

name of the authority designated  to  perform  a  given  function

makes  it possible to restrict arbitrary hosts from abusing their

ability to emulate a GMCC.


4.2  The Hosts


     Members of the ARPANET NCC staff have asserted that  "a  key

factor  in  network  maintainability is the centralization of the

responsibility  for  providing  adequate  user  service.    Since

service   is   best  defined  at  the  man/machine  interface,  a

significant gain in maintainability would come about if the  user

interface  were  completely  at  the  man/machine  boundary.   By

including a host within the sphere of responsibility  of  network

maintenance,  there could be more uniform and speedier resolution

of problems within that host.  Since the  network  design  allows

for  dissimilar  node programs, not much additional complexity is

required to maintain a set of dissimilar service  hosts.   (Thus)


                             - 11 -

the  scope  of  the  network should be expanded to providing user

services with corresponding benefits for both unified design  and

maintainability."

     This  may be an extreme position, and may not actually be as

easy as anticipated by the NCC staff, but nevertheless  it  is  a

position  which has at least some validity, especially in view of

the fact that gateways are themselves just hosts, and much of the

modelling performed for gateways can thus  be  applied  to  other

general purpose hosts.

     Consider  what  Monitoring  and Control might be possible if

some small component of the host's network software, such as  the

TCP  program,  were instrumented to allow Performance Monitoring,

Event  Recording,  etc.   under   control   of   a   GMCC.    The

instrumentation  would  simply provide that the TCP keep track of

its events of interest and arrange for them to be made  available

in  a  convenient way to some other protocol module (perhaps) for

transmission to the GMCC.  In addition, if there is to be Control

of a TCP, some internal means should be provided for a process to

direct certain actions of the TCP (for example the  resetting  of

accounting statistics).

     Certain other capabilities might also prove useful.  The TCP

should  be  able  to report to the GMCC any errors it observes in

packet formats, packet delivery, etc. so that host personnel with

a reliable TCP implementation need not be concerned  about  error

analysis  for  newly  added,  undebugged hosts, say.  The GMCC is

certainly in the appropriate position to  be  able  to  correlate

abnormal  TCP  interactions with Catenet component outages and be


                             - 12 -

able to explain the abnormal behavior to the host via messages to

the TCP.  The TCP should be able  to  be  instructed  to  discard

certain messages or to echo them back to their source.  It should

perhaps  be  able to timestamp and trace various messages.  These

kinds of activities would all be possible  given  an  appropriate

and  uniform  instrumentation of the various TCP implementations.


4.3  The PSNs


     The links of the Catenet are the local PSNs.   Unlike  usual

network  links,  these  links  are  equipped  with  a  processing

capability in the form of their own node computers or  their  own

NCC  hosts, etc.  Whatever form this processing capability takes,

it can presumably be  made  to  communicate  with  other  Catenet

components   using   the   protocols  for  GMCC-to-component  and

component-to-GMCC communication.  The local PSNs should  be  able

to  report  errors  in interfacing which occur at the PSN/gateway

interface; they can also report gateway ups  and  downs  as  they

observe them; they might be instrumented to assist in tracing and

looping  of  messages  sent  to or through them;  they could keep

track of the length of gateway outages;  and since the PSN is the

only component with hardware (in most cases) connections  to  the

gateway  and  host components, it can perhaps help in the restart

or reload of these components.  The techniques for performing any

of these activities should be carefully and completely  modelled.








                             - 13 -

5.  A MODEL FOR THE GATEWAY COMPONENT


     The  principle thing we expect a gateway to do is to perform

message routing; a suggested routing mechanism  is  presented  in

IEN  No.  30, "Gateway Routing: An Implementation Specification",

by  Strazisar  and  Perlman.   Beyond  this,  there  are  several

secondary  activities  in which the gateway must play a role, and

the large majority of these can be clustered  under  the  general

heading  of  Monitoring and Control.  These are the activities we

are most concerned with here.  As discussed earlier, the  gateway

component,  like  any  other component, should be instrumented to

include mechanisms which allow it to cooperate  with  a  GMCC  in

providing  Performance  Monitoring,  Event  Recording, Functional

Testing, and Component (i.e. gateway)  Maintenance.   It  is  the

role of the model to identify the mechanisms which should be used

within the gateway to provide these various functions.


5.1  Considerations Affecting the Design


     The  intent of this section is to give some insight into the

process by which the model for  the  gateway  component  will  be

developed.   There  are  a  number  of fundamental considerations

which should be stated beforehand because of their impact on  the

way we want to think of gateways as an entity and thus on the way

we think of the necessarily composed.  The first of these is that

a gateway should be considered to have a net-independent part and

one or more net-dependent parts.  The net-independent part should

be  considered  the  heart  of the gateway -- the place where the



                             - 14 -

common functions of routing, flow  control,  etc.   are  actually

performed; this part is hopefully divorced from considerations of

the networks to which the gateway is attached.  The net-dependent

parts  on the other hand may all be different, since the networks

in most cases will be different, but each should  have  the  same

eessential  structure:  there will be modules which gate messages

to and from the attached net, and modules which append or  remove

local headers to or from internet (and other) messages, etc.  One

of  the challenges for the model designer and gateway implementer

is to carefully design the boundary between the net-dependent and

net-independent functions.



     The gateway model should be able to  accommodate  more  than

one   type   of  gateway  implementation.   That  is,  it  should

accurately describe or apply to implementations such as:

   - the  conventional  gateway.   This  is  a  single  processor
     performing  gateway functions only and connected to only two
     nets.

   - a two- or multi-processor gateway.  This  is  a  distributed
     implementation  of  the  gateway, such as the "half-gateway"
     model once considered; the mechanisms used by  the  separate
     processors  to communicate with each other should not affect
     the model design.

   - gateways within general purpose host  processors  where  the
     gateway  program is just one of several that may want access
     to the network.

   - gateways connected to three or more networks.

   - gateways  using  only  a  single  net  interface.   Such  an
     arrangement  might  result  if, for example, a single medium
     were used by two different nets.  readdressing, say, ....

   - both  big  and  small  (in  terms  of  power,  size,   cost,
     capability) gateways (including very simple - perhaps purely
     hardware - implementations).


                             - 15 -

   - existing ARPANET gateways.

   - existing othernet (sic) gateways.

   - the gateway module which sits between a host TCP,  say,  and
     the  network,  and  whose  job it is to select a destination
     gateway consistent with the destination host.

   - a gateway with two or more interfaces to a  single  network.

   - a gateway which is (either always or sometimes) unwilling or
     unable  to  participate in Monitoring and Control exercises.

   - gateways  which  are  responsible  for  access  control   or
     authentication.   The  need  for these special functions may
     impact the form of certain mechanisms proposed  for  use  in
     the model implementation.

   - gateways which need to perform fragmentation  or  reassembly
     of  encrypted  data  messages,  or  which need to be able to
     understand special packet  formats  associated  with  secure
     data transmissions.

   - gateways which may without warning turn into "one-way" paths
     only for such applications as military EMCON.






5.2  The Beginnings of a Model



     There  are  several  kinds  of information which the gateway

should be able to exchange  with  the  GMCC  in  support  of  its

Monitoring and Control activities.  Among them are:

   Administrative Information

     This  is  information  that  identifies the gateway uniquely
     among all the components of the composite Catenet.  To get a
     proper picture of the net at any given time,  a  GMCC  would
     like to be able to discern, among other things,

       the computer type
       the memory size
       the  gateway characterization (conventional, ARPANET, ...)
       the Administrator's name, address, phone number
       the program size, release number, release date and time


                             - 16 -

       the addresses of hosts serving as GMCCs
       the names of connected nets, etc.

     Information such as this may best be sent unsolicited  to  a
     special  service  host  when a gateway first comes up on the
     net after some outage;  interested experimenters could  then
     retrieve  the information from the host much as is currently
     done in the ARPANET for retrieving Host status  information.

   Measurement Information

     This  information is simply the collective set of statistics
     accumulated by  the  gateway  during  its  operation.   They
     reflect the processing performed by the gateway in servicing
     internet traffic.

   Monitoring Information

     This is primarily the "up/down", "up for how long", "planned
     outages", "recent crash explanation", "net interface reset",
     etc.  kinds  of  information  which dictates to the GMCC the
     status  and health of the gateway component.

   Control Information

     This is either the information sent by the GMCC to cause the
     gateway to enter a test, reload, or, restart  mode,  or  the
     information  sent  by  the gateway to the GMCC to report the
     results of component testing, to dump some  of  its  memory,
     etc.

   Debugging Information

     Patterned  after  a  general purpose time sharing host's DDT
     program which has complete control  over  the  execution  of
     subservient   programs,   the  information  associated  with
     debugging includes commands to read or write a cell, to  set
     or  reset  (pseudo)  breakpoints, to search memory, etc. and
     the responses to these commands.  Two kinds of DDTs may have
     to be accommodated in any given gateway implementation,  one
     to  be used by experimenters, say, and one, like XNET, to be
     used during initial debugging.

   Descriptive Information

     This is the information which conveys to the GMCC  the  list
     of  capabilities  possessed  by  the  gateway; it includes a
     listing of the kinds of information collected  and  reported
     by  the  gateway,  a characterization of queue capacities, a
     list of settable operational parameters,  a  description  of
     the  histograms  maintained  by  the  gateway, a list of the
     protocols  supported,  etc.   It  responds  to  the   GMCC's
     questions  about  "what  can you do", "how much can you do",
     etc.

                             - 17 -

   Experimental Information

     This is the information associated with the manipulation  of
     the  component  by experimenters.  It is in part descriptive
     (experimenters can ask what experiments are supported,  what
     parameters   are   allowed,  what  range  on  parameters  is
     accepted,  etc.),  in  part  control   (they   can   request
     initiation  of an experiment), and in part measurement (they
     can  request  operational  statistics  associated  with  the
     experiment),  but  it  seems reasonable to distinguish it as
     distinct from these other  operational  aspects  insofar  as
     possible;   not  all  gateways  which  provide  descriptive,
     control,  and  measurement  information  will  also  support
     experimental use.

   Accounting Information

     This  information  is  basically  the  set of raw statistics
     which should be used by an administrator  for  charging  for
     gateway  utilization.   It is reasonable to distinguish this
     information from pure measurement information  since  it  is
     not  necessarily  of  interest  to  a  GMCC  worrying  about
     functional capabilities, and will likely have to be reported
     to some special host rather than a general purpose community
     GMCC.

   Operational Information

     This is included here just as a reminder that in addition to
     manipulating all the information associated with  Monitoring
     and  Control  activities,  the  gateway  will  also  want to
     occassionally handle internet  messages,  routing  messages,
     and  the  rest  of  the  information that is its "reason for
     being" in the first place!



     Note that it is possible to consider  that  each  individual

kind  of  information  is  associated  with  a particular kind of

"event"  which  occurs  within  a  gateway.   Thus  we  may  have

Measurement  events,  Monitoring  events, and even Administrative

events within a functioning gateway.  It is also the role of  the

gateway  model  to specify how these events are to be recognized,

recorded, reported, caused, prevented, suspended, continued, etc.





                             - 18 -

     At least three notions are central  to  our  discusionss  at

this  point.   First,  we   have the four basic functions that we

have discussed in detail before:  Performance  Monitoring,  Event

Recording, Functional Testing, and Component Maintenance.  From a

suitable,  high level external viewpoint, these are the functions

that the gateway is involved in.  Second, we have  the  different

kinds  of  information  which must be recorded by the gateway and

transported between the gateway and  the  GMCC.   Each  different

kind  of  information  implies  possibly  a  distinct  formatting

requirement, distinct collection mechanism, etc.  Finally,  there

are  the several different mechanisms which must exist inside the

gateway that can be used  to  collect,  record,  and  report  the

different  kinds  of  information.   The most apparent mechanisms

which  exist  in  the  gateway  implementations  are   processes.

Processes  are the addressable resources which carry on dialogues

with the GMCC and with each other in some cases.  In addition  to

the  distinct processes, there are other mechanisms which we will

just label as  "routines".   Routines  are  best  thought  of  as

utility  functions  which  may  be  invoked by any of the gateway

processes  to  help  each  get  its  collecting,  recording,  and

reporting  done.  An  example  of  a utility routine might be one

which formats a message  according  to  gateway-to-GMCC  protocol

specifications  and  adds  it  to a queue of messages to be sent.

Examples of processes are

        - the monitoring process which generates the periodic and
          spontaneous  reports  to  the   GMCC   describing   the
          operational status of the gateway.




                             - 19 -

        - the  measurement  process  which  delivers   cumulative
          statistics to the GMCC.

        - the echoing process which returns all received messages
          to the source from which they originated.

        - the memory transport process which  moves  portions  of
          the  gateway  memory  (programs or data) to or from the
          GMCC.

        - the terminal  handling  process  which  excanges  ASCII
          character  streams  between  the gateway's terminal (if
          one is present) and a specified internetwork source  or
          destination.

        - the debugging process.

        - the message generator process.

        - etc.




     It  should  be obvious that processes do not deal one-to-one

with the kinds  of  information  we  discussed  above.   A  given

process,  such  as the measurement process, may be used to report

the  cumulative  statistics  of  each   of   several   kinds   of

information.  Alternatively, it may take more than one process to

deal with all the information of any particular kind; for example

experimental information as discussed above.  And it is certainly

likely that multiple distinct processes will have a need to share

a  single  common  routine whenever their processing requirements

are identical; for example, tracing of  messages  sent  from  the

GMCC  to  the debugger, to the echoer, or to the terminal handler

should be done by having each process (conceptually)  invoke  the

single  trace  mechanism.   It  may  also  be  the  case that two

processes can be cascaded for the purpose of combining  different

kinds of information into a single net message.


                             - 20 -

5.3  A Sample Modeling


     We  will  develop  the  gateway  model in terms of a general

purpose host's implementation, since this allows inclusion of  as

much   mechanism   as   may   be  useful  for  the  more  general

implementation.  The figure below shows the principle  components

of  the  input  handler  for  a  net-dependent  part of a general

purpose gateway.


First there is a hardware component which represents the physical

interface  between  the  network  and  the   gateway   processor.

Obviously this interface will be different for different nets and

for  different processors, but as a model component should always

correspond to some real chunk of hardware in any  implementation.


Second,  there  is  a  piece  of code which serves to control the

input portion of the net interface hardware.  Its basic  function

is  to  effect  the  reading  of  messages  from the network into

gateway memory. In  the  process,  it  may  perform  intermediate

parsing, do checksum and consistency processing, etc.


Third,  there  is  a message queue where unparsed messages reside

after they have been received by the net  interface  routine  but

before  they  have  been  processed by any other gateway routine.

This queue may be implemented in any of  several  ways,  and  may

only  have  room for a single message in some implementations. (A

"higher" level routine may perform queue management in this case,

using a different data structure.)




                             - 21 -

                             - 22 -

Fourth, there is a second routine depicted whose  job  it  is  to

parse  the  received  messages  one-by-one  and  distribute  them

individually to new message queues based on the contents of their

local network header.


Finally, there are several model components (including both  data

structures  and  routines) which are not pictured, but still must

be modelled; a subsequent and more complete modelling effort will

certainly include them. These are data   structures  like  buffer

pools and routines like buffer managers, etc.



     Associated with these model components are a large number of

parameters,  both  static  and  operational. These are the things

we've been calling "events".  In the following we give a sampling

of the events  of  interest  for  each  of  the  event  types  we

identified  before.   The  sampling  is  not  complete, but it is

representative of the kinds of information we might be interested

in  for  purposes  of  Monitoring  and  Control  in  the  gateway

modelling.   Of  course,  not  all  of  the  events  are of equal

interest or value;  as modelers, we should attempt to identify as

many as we can, and leave  to  the  individual  implementers  the

selection  of  which  events  they really want to record, report,

etc.


Events of Interest:

   Administrative -

        the name and manufacturer of the hardware interface




                             - 23 -

   Measurement -

        a histogram of log[base 2] message sizes
        message counts for each distinct local header type


   Monitoring -

        cumulative uptime
        number of interface errors


   Control -

        reset counters
        place a message on the input queue


   Debugging -

        read the hardware status register


   Descriptive -

        Fan out for local headers
        queue size
        maximum message size


   Experimental -

        discard every second message at the interface


   Accounting -

        total bits received at the interface







5.4  Continuing the Sample Modeling


     In this section we  continue  the  sample  model  introduced

above  by showing how certain of the data paths might be extended

to account for subsequent message processing.  It should be  easy


                             - 24 -

to  identify  the  events  of  interest in this extension given a

little thought.  Subsequent attempts at modelling will  enumerate

these   in   detail.    Note  that  there  are  probably  several

alternative ways of  depicting  these  later  stages  of  message

processing;  this fact is compounded by the fact that this is the

point      in      message       processing       where       the

net-dependent/net-independent  boundary  may be crossed.  Further

discussion of alternatives to this part of the model is postponed

to the section entitled "Issues".



     Figure 2 shows the extension to the model.  It begins  where

the  previous figure left off.  First, note that at this point we

have separated the various types of messages arriving at the  net

interface into unique queues according to indicators in the local

header.  For this figure we will follow only a single path -- the

one followed by internet messages which carry the normal internet

traffic.   These internet packets are removed from their queue by

a routine which separates them again, this time according to  the

version  bit,  into a queue of messages which employ the previous

internet formatting conventions and a  queue  of  messages  which

employ the current conventions.


From  this latter queue, the messages are sent to another routine

whose job is to initiate the option processing.  In Figure 2,  we

have  represented  the  options  as  subroutines  without further

elaboration; subsequent versions of the model should provide  the

elaboration.



                             - 25 -

                             - 26 -

Finally,  after  option  processing,  the messsages are separated

again into individual queues  according  to  the  values  in  the

protocol   field.   Here,  separate  queues  may  be  formed  for

unrecognized protocols, previous and  current  versions  of  TCP,

gateway  routing  messages,  and  eventually  the  Monitoring and

Control messages, the Datagram Protocol, the Real-Time  Protocol,

etc.


     As  stated,  we  will  not  elaborate  here on the events of

interest for this part of the model; some should be obvious.





































                             - 27 -

5.5  Unresolved Issues


     In this section we want to address a number of issues  which

are  not  yet resolved in the modelling of the gateway component.

Their resolution will probably depend on prolonged discussions in

certain cases, on snap decisions in  others;   possibly  in  some

cases  a  satisfactory  resolution  will  not  be  possible,  and

whatever alternative solutions are proposed will all have  to  be

included in a generalized modelling to make sure the modelling is

comprehensive enough.

     At any rate, the topics which need further investigation are

presented below.





5.5.1  Are the Event Types Correct


     First  there  needs  to  be  some general agreement that the

event types (information types) we have identified are sufficient

for modelling purposes.  It is probably the case  that  they  are

correct   enough  for  a  beginning,  and  that  no  particularly

disruptive perturbation of the model would be caused  if  another

event  type  had  to someday be accommodated or an existing event

type had to  be  deleted.   However,  the  omission  of  an  XNET

information   type   (not   to  be  confused  with  the  distinct

"debugging" type) may have to be remedied before too long.








                             - 28 -

5.5.2  What Information Should be Communicated to the GMCC


     Here there is a lot of room for varying opinion.   The  next

cut at the model will try to identify as many potential events of

interest as possible.  Obviously, not all these events will be of

interest  to  all  implementers;   that's  why the Monitoring and

Control mechanisms  must  be  sure  to  allow  for  only  partial

participation  on  the  part  of  any  particular implementation.

However, it may also be the case that we omit some event that  is

of  particular  interest  to  some  gateway  implementer,  or the

information which we choose to record  about  the  event  is  not

quite   what   is  needed  for  some  implementer's  needs.   Our

collection mechanism  must  be  flexible  enough  to  accommodate

extensions at any time.

     Here the real issue may be how to control, administratively,

the  selection  of  events  of  interest  so that all parties are

satisfied with the set selected.



5.5.3  How Should Information be Communicated to the GMCC


     We are  of  the  opinion  that  in  most  cases,  the  basic

gateway-to-GMCC   communication   facility   should  be  datagram

oriented on the basis that (1) connection  overhead  may  be  too

expensive  for  certain gateway implementations, that (2) no flow

control is  probably  needed  since  the  gateways  will  not  be

generating  data  too  frequently  and since GMCCs will generally

have substantially greater storage  and  processing  capabilities

than will the gateways, and that (3) a practical reporting scheme


                             - 29 -

can  probably  be  developed  in  which  lost  messages  will not

necessarily represent lost information, merely  delayed  delivery

of  information,  since  the  contents  of  lost  messages can be

inferred from later messages, (this is the  case  for  cumulative

statistics for example);  on the other hand, the datagrams should

carry  sequencing information, and will of course employ standard

Internet Headers.

     Datagram service will be  satisfactory  in  most  cases,  we

hope.   In certain instances, however, reliable transmissions may

be extremely important;  for  these  instances,  some  additional

capability  may  have  to be added.  As yet, we have no real feel

for the capabilities required; thus this is still an open  issue.

Also  at  issue  is  the decision as to whether internet messages

directed at the various gateway  processes  should  all  carry  a

single  protocol  designator,  or  whether each different message

type should command a distinct designator.  It is not  yet  clear

whether  minimal  gateway implementations would find it easier to

process messages formatted in one way vs. the other,  or  whether

it  is  too  wasteful of the Internet Header's protocol field, or

whether it is easier one way or the other  to subsequently add or

delete new message formats.

     Beyond these basic  issues,  there  is  also  the  issue  of

message  formats  and  message content.  Two alternatives present

themselves as regards event  reporting.   We  assume  that  event

counters  can be maintained in 16-bit words,  say.  We can insist

that messages contain a fixed  number  of  counters  in  a  fixed

order,  and  thus  eliminate  the  need  to  transmit descriptive


                             - 30 -

information with each reporting message.  Or, we  can  allow  for

every  counter  to be accompanied by another word which names the

counter.  Tradeoffs  between  the  two  strategies  are  not  yet

properly understood.



5.5.4  Addressing Processes from Outside the Gateway


     Each  of the gateway processes responsible for some activity

of Monitoring and Control has a unique identity, or name,  within

the  Catenet.   But  because  the gateway is attached to multiple

nets, it is possible for each process to have  multiple  distinct

addresses.   We  can assume that one reasonable modelling for the

net-dependent  input  handler  requires  the  input  handler   to

recognize  at  the  net  interface  all the messages addressed to

processes which share its own net (and host)  address.   This  is

the  case  for example in a general purpose implementation of the

gateway, since the general purpose input handler doesn't normally

receive messages for processes  that  don't  share  its  own  net

address.  It probably should not be the responsibility of a given

net-dependent input handler to be aware that it is playing a role

in  a  gateway  implementation,  and  thus to be cognizant of the

alternative internet addresses of the gateway processes it thinks

of as its own;  i.e. the net-dependent code should  not  have  to

know  what other nets the gateway is connected to.  Therefore, if

a message arrives at one net interface that specifies a  resource

(process)  whose  net address is different from that of the input

handler, then the message  should  simply  be  handed  off  to  a



                             - 31 -

special  process  which can effect the proper disposition for the

message without further involvement of the input handler.

     Figure 3 depicts this arrangement.


Here, each network has its own interface to a common copy of  the

gateway  process,  so  that  it  can communicate with it directly

whenever a message arrives which addresses the  process  via  the

appropriate  net.   However,  when  a  message  is received for a

destination not known to the input handler, the message is simply

handed to the special process, which in this figure  is  referred

to  as  the "Postman".  Note that the Postman can effect delivery

to the processes  via  its  own  interface,  so  that  successful

delivery  does  not  depend  on  the  route taken by the message.

(Note that the model might want to specify that  the  Postman  be

able  to  add  messages  to the input queues of the net-dependent

input handlers as a means for effecting  delivery  in  a  uniform

way.)    The   Postman  here  also  has  the  responsibility  for

performing the tasks associated with the routing of  messages  to

distant  locations.  That is, messages input at the gateway which

are only passing through should be routed by the general  gateway

routing  algorithms;  these can be implemented by the Postman, or

by some other process to which the Postman interfaces.


     There  is,   of   course,   another   way   to   model   the

net-dependent/net-independent  boundary.   Figure  4  shows  this

other way.






                             - 32 -

                             - 33 -

                             - 34 -

Basically the difference here is  that  the  net-dependent  input

handlers   no  longer  have  their  own interfaces to the gateway

processes.  Instead, they simply pass all  received  messages  to

the internal Postman and allow it to effect delivery.  This is an

acceptable   approach   even  if  in  the  general  purpose  host

implementation the net-dependent input  handlers  still  have  to

worry  about  interfacing  processes  which aren't using Internet

Headers.  However, in this model, the Postman  and  the  affected

processes  must  be  sure  to not lose the destination address by

which they were reached, lest they not be able to  use  the  same

address  for the source in the header of their response messages.

(We are somehow assuming that the recipient of  a  message  whose

source  address  does not match the destination address which was

used for  transmission,  will  not  be  anxious  to  perform  the

required reverse lookup to map the source address into a resource

name.  If we were to model this capability, it is not clear where

the processing for this lookup would be performed.)

     At issue here then is just exactly which of these two models

should be assumed for "the" model implementation.



5.5.5  Addressing Processes from Inside the Gateway


     Here  is  an  issue  which  has certainly been touched on in

other internet meetings; it is basically a discussion of the need

for  high  level  protocols  to  carry   their   own   addressing

information.





                             - 35 -

     Gateway  processes  will  have occassion to communicate with

other  processes  in  support  of  gateway  routing  or   gateway

Monitoring  and  Control.   Traffic between two gateway processes

may  be  intrahost,  intranet,  or  internet,  depending  on  the

relative  locations  of the source and destination processes.  At

issue is whether in all cases a single  data  transport  protocol

should  be  used  to  effect  message  delivery.  We have already

"concluded" in the discussion of  event  reporting  that  gateway

Monitoring and Control messages should employ Internet Headers in

all  cases.  And it would certainly seem on the surface that this

scheme is ideal.  However, in certain cases this may not be true.

     We are struck by an inconsistency which arises when  we  try

to   attain   symmetry   in   modelling  the  gateway's  internal

organization.  At one point in the model, we have a process whose

job it is to route messages through a given local net.   Whenever                                            _________

it  is  handed an internet message, it analyzes the header of the

message in order to determine the desired destination, and  hence

what local address to specify in the net-dependent data transport

protocol.

     The   inconsistency   is  found  because  we  don't  have  a

corresponding process whose job it is  to  analyze  higher  level

protocol  headers in order to route messages through the internet                                                         ________

(using the internet data transport protocol).  This means  either

that each of our Monitoring and Control processes must make up an

Internet  Header itself, or that, if some common process is to do

it, the common process must be handed the addressing  information

by  some  "out-of-band"  path  (such  as  a shared memory control


                             - 36 -

block).  This may not  be  easy  to  provide  for  a  distributed

gateway implementation, say.

     The  real issue here, of course, is inspired by the problems

we see for, say, TCP users,  if  the  Internet  and  TCP  Headers

recently  proposed  are adopted for use in the Catenet.  The fact

that higher level protocols are being designed which don't  carry

their  own addressing information means that these protocols will

be practically unusable in any instance where the data  transport

protocol  used  to  carry the messages is different from the data

transport protocol embodied in the  Internet  Header.   TCP,  for

example, would probably not be usable without Internet Headers in

the ARPANET, since port addressing would be impossible.

     Although  it  is  probably  the case that we will not opt to

include addressing information in the messages  which  adhere  to

our  higher level Monitoring and Control protocols, and will thus

in fact choose to use the Internet Header to provide  addressing,

we  nevertheless  wonder  if  it  is wise to arbitrarily restrict

these  protocols  to  use  with  only  a  single  data  transport

protocol.


















                             - 37 -