IEN 104



             Minutes of the Fault Isolation Meeting

                         12 March 1979


                      Virginia Strazisar



                    Bolt, Beranek, and Newman

                          20 March 1979

Minutes of the Fault Isolation Meeting held at BBN on March 12

Attendees:
Virginia Strazisar, BBN, chairman
Peter Sevcik, BBN
Dale McNeill, BBN
Noel Chiappa, MIT
Ray McFarland, DOD
Mike Wingfield, BBN
Jack Haverty, BBN
Bill Plummer, BBN
Mike Brescia, BBN

Ginny suggested that there are three situations  in  which  fault
isolation  is  needed:   1) the user at a terminal on the catenet
who cannot reach some destination on the catenet,  2)  a  catenet
control  center  that  must decide what network or gateway in the
catenet has failed, and  3)  the  gateway  implementor  who  must
decide  what part of the gateway hardware or software has failed.
These situations were put forth as a framework for discussing the
types of fault isolation facilities that we need.   Ginny  stated
that  the  object  of  the meeting was to draw up a list of fault
isolation tools needed,  giving  special  consideration  to  what
situations  each  of  these  tools  would  be  used  in  and what
questions they could be used to  answer.   From  the  suggestions
drawn up at the meeting, the detailed formats and protocols could
be designed; this level of design was specifically avoided at the
meeting.

The first situation discussed was the user at a catenet terminal,
who  discovers  that  he  either  cannot  connect to a particular
destination host or that he no longer gets any response from  his
previously  working  connection.   At  present  no information is
passed to the user in either of  these  cases.   Everyone  agreed
that  the user should receive some error reply.  It was suggested
that the user should receive a response indicating that either 1)
the destination host is unreachable,  2)  the  local  gateway  or
network  is unreachable or 3) the catenet is inoperational.  Most
people agreed that the naive user does not care to know what  the
catenet  problems are in any more detail than this.  For example,
an error messgage of the form "Can't  reach  destination  network
because  gateway 3 is down" would be totally useless to the naive
user.  The user also wants to  know  when  the  service  will  be
restored,  either  "within  a  short  time" such that the user is
willing to wait for the service to be restored;  or  "not  for  a
long time" such that the user will quit trying to use the service
at   this   time.    Several  people  pointed  out  that  a  more
sophisticated user may want to know exactly what component of the
catenet failed.  There was some discussion as  to  whether  users
should  be  given access to tools that would enable them to probe
the catenet gateways to determine  where  the  failure  occurred.

The consensus of opinion was that the user should be given access
to  such  tools,  but that no user should be required to use such
tools.  Our model was that the naive user on receiving  an  error
message  would  call a network or catenet control center, whereas
the more sophisticated user may attempt to track down the problem
before contacting the  control  center.   We  discussed  in  more
detail  what  sort of message a gateway could return to the user.
It was suggested that if the network returned  an  error  message
about  a  specific  host that that error message (text) should be
returned verbatim to the user.  It was also suggested that  error
codes be defined for "common" failures, i.e. net down, host down,
and  that these be included in the error message.  It was pointed
out that the gateways currently return  messages  to  the  source
host  if  they  believe (based on their routing information) that
the destination network is unreachable.  These  messages  contain
the  source and destination addresses and the protocol field from
the original datagram.  Several  people  pointed  out  that  this
information  is  insufficient  to  return an error message to the
source user and that the entire internet header of  the  original
datagram  should  be returned in the error message.  We discussed
the problem of what to do in the case where datagrams are lost in
a gateway or network in such a manner that no  error  message  is
generated  and  returned  to  the source.  It was decided in this
case that the source host should automatically probe the gateways
in order to return a reasonable status message to the  user.   It
was  assumed  that  the user is running a program that implements
some type of internet  protocol,  such  as  TCP,  and  that  that
program   is   capable   of  detecting  long  delays  or  mutiple
retransmisssions and of generating some type of probe  packet  to
attempt  to  track  down  the  failure when this occurred.  These
probe packets are discussed in more  detail  below.   Information
obtained  from  such  probing  could also be sent to a monitoring
center.

We discussed the concept of a monitoring or control center.   The
primary  purpose  of  a  monitoring or control center in terms of
fault isolation is to isolate the component (network or  gateway)
that  failed and to notify the proper authority to have it fixed.
We felt that a control center was needed to avoid having all  the
users  in  the catenet calling any and all implementors they felt
might be responsible for  problems.   The  concept  of  a  single
control  center was discussed and rejected for both technical and
political reasons.  From the technical  point  of  view,  it  was
pointed  out  that the catenet could become partitioned such that
the control center was cut off from part of the catenet and  thus
could no longer handle faults in that portion of the catenet.  On
the  political  side,  it  was  pointed  out  that  organizations
responsible for the  individual  networks  may  be  unwilling  to
support  one  control  center run by one organization.  We agreed
that the catenet  control  center  should  actually  be  multiple
control  centers.   These  could  be  either the existing network

control centers  working  in  co-operation  or  separate  catenet
control  centers,  each  of which was established by co-operating
network groups.  Tools that  these  control  centers  would  need
included  a  facility  to  probe  gateways  to  determine  why  a
particular destination was unreachable.

We elaborated slightly on the design of a  facility  for  probing
gateways.   A  host  or  control center sends its local gateway a
message saying "poll the gateways in the catenet to determine why
I can not get to destination X".   The  gateway  then  polls  its
neighbors,  its  neighbors'  neighbors,  etc., extracting routing
tables,  addresses  of  neighbor  gateways,  status  of  neighbor
gateways  and  networks, etc. to determine why the destination is
unreachable.  The gateway would then formulate a response to  the
host;   this  response  would  be  of  the  form:   "the  network
connection between gateway 3 and net 2 is down", "gateway  5  and
gateway  6  are down", etc.  This mechansim would be an extension
of the gateway-gateway protocol as  defined  in  IEN  #30.   This
probe  facility  would  be  used by the source host to generate a
message to the user in the case where  no  response  is  recieved
from  the  destination  and  no  error message is returned by the
gateways.  The facility would also be  used  by  catenet  control
centers to isolate the componenet of the catenet that has failed.

It  was  pointed  out  that  we should be concerned not only with
total failures, but  also  with  system  performance,  especially
delay.   In  this context, we were not concerned with cases where
delay seemed slightly longer than  usual,  but  rather  cases  in
which  traffic  crossed  the catenet with extrememly high delays,
i.e several minutes.  A facility was suggested to track this sort
of problem:   generate  a  packet  from  source  A  addressed  to
destination  B; have this packet trace its route and timestamp it
at each gateway on the route to B; at B, echo the packet;  return
the  packet  to the source, A, using source routing and the route
stored in the packet via  the  trace  mechanism;   timestamp  the
packet  on  its  route  back  to A.  The timestamps in the packet
could now be interpreted  to  yield  transit  times  across  each
network  as  there would be a pair of timestamps for each gateway
traversed.

The final stage of fault isolation is the situation in which  the
failure  has  been  attributed  to  a  particular gateway and the
implementor of that gateway must debug it.  This  part  of  fault
isolation  was not discussed in detail.  It was suggested that at
this point, it would be very  useful  to  be  able  to  turn  off
timeouts  in the catenet to avoid having the state of the catenet
change in such a way that the problem can no longer be  isolated.

In  summary,  the following list of tools and situations in which
they would be used was suggested.

1)  Error messages indicating whether the destination  host,  the
local  network  or  gateway,  or  the  catenet  had  failed,  and
indicating the time at which service should be restored.

These are to  be  returned  automatically  to  the  catenet  user
whenever there is a failure in using a catenet service.

2)   Gateway  to  gateway probing mechanism that can be initiated
with a host to gateway message.

This mechanism would be used by a control  center  to  isolate  a
component  failure.   It would also be available to the user.  It
would be used by source host protocol programs  to  formulate  an
error message for the user when no repsonse was received from the
destination  and no error message was received from the gateways.

3)   Ability  to  trace,  echo  and  source  route  packet   with
timestamping.

This  facility  would  be  used  to  determine  where  delays are
occurring when a destination is reachable, but delays  cannot  be
accounted for.

4)  Ability to echo packets off any gateway.
5)  Ability to trace packets.
6)  Ability to source route packets.
7)  Ability to dump gateway tables.
8)  Ability to trace packets by sending replies from every
gateway that handles the packet.

These  capabilities  would be used by control centers and gateway
implementors to  isolate  failed  components  and  determine  the
reasons  for  failure.   These  facilities  were not discussed in
detail.  A description of  mechanisms  for  tracing  packets  and
source  routing packets was given in IEN #30, although these have
not yet been implemented.

The next step in developing fault isolation  mechanisms  for  the
catenet  is  to  work  out the detailed design for the mechanisms
suggested above, and to implement these in  hosts,  gateways  and
control centers.

mirror server hosted at Truenetwork, Russian Federation.