<NIS.NSF.NET> [IMR] IMR86-12.TXT
Westine [Page 1]
~
DECEMBER 1986
INTERNET MONTHLY REPORTS
------------------------
The purpose of these reports is to communicate to the Internet Research
Group the accomplishments, milestones reached, or problems discovered by
the task forces and contractors in the ARPA Internet Research Program.
This report is for research use only, and is not for public distri-
bution.
Each task force and contractor is expected to submit a 1/2 page report
on the first business day of the month describing the previous month's
activities. These reports should be submitted via ARPANET mail to
Westine@ISI.EDU.
Reports are requested from BBN, ISI, LL, MIT-LCS, NTA, SRI, UCL, and
UDEL.
Other groups are invited to report newsworthy events or issues.
BBN LABORATORIES AND BBN COMMUNICATIONS CORPORATION
---------------------------------------------------
ARPANET STATUS
As members of the Internet community know, the ARPANET is at the
core of the Internet. Performance of the ARPANET impacts perfor-
mance seen by the entire Internet community, just as behavior of
users of, and the performance of, other networks impacts the
Westine [Page 1]
Internet Monthly Report December 1986
traffic carried by the ARPANET. In late summer and early fall of
1986, the ARPANET experienced severe performance problems. The
occurrence of these problems led DARPA, DCA, and BBNCC to focus
greater attention on the ARPANET, with a view towards taking steps
to correct the immediate problems as well as towards making
longer-term improvements to the network. As a part of this
increased attention to the ARPANET, we will now include a brief
ARPANET status update in its Internet monthly reports. In order to
bring the community "up to speed" on the ARPANET situation, our
first report is necessarily a lengthy one.
Over the past year and a half, traffic carried by the ARPANET has
increased approximately 33%. However, the topology and capacity of
the ARPANET is essentially the same as it was at the time of the
ARPANET/MILNET split in late 1984. The user community is moving
strongly towards a pattern of LAN and Gateway attachment of hosts
to the network, resulting in increased concentration of traffic
through a proportionately smaller number of ARPANET PSNs and PSN
host ports than was formerly the case. In fact, fully 85% of the
traffic handled by the ARPANET has an Internet Gateway as its
source or destination. In addition, a topology change in the net-
work stemming from the relocation of a network node at USC in
August resulted in a 19.2 kb/s circuit on the USC campus being
placed at the West Coast end of one of the ARPANET's three cross-
country routes. All of these factors contributed to the severe
congestion experienced by users in September and October.
Since that time, the ARPANET has had some "ups" and some "downs".
The topology of the network was rearranged to remove the 19.2 kb/s
circuit from the cross-country path, and a line between Purdue and
Wisconsin was restored to the network. C/30 PSN parameters were
adjusted to equalize propagation delay across the three cross-
country routes, and PSN and TAC software was brought up to current
releases. In addition, routing parameters in the Wideband Net But-
terfly Gateways were adjusted so that inter-LAN traffic would favor
the Wideband Net over the ARPANET.
These steps, taken together, produced a significant improvement in
ARPANET performance between early October and early November. Mean
Round Trip delay was halved from 625ms in early October to approxi-
mately 300ms. "Traps" indicating congestion reported by the C/30s
to the ARPANET Monitoring Center dropped by an order of magnitude.
ARPANET capacity remains critical, however. This was demonstrated
in late November and through most of December, when two key cir-
cuits, one between CMU and DCEC, and the other between TEXAS and
BRAGG, were out of service for extended periods. During this time,
delays and congestion were once again prevalent, and congestion
traps increased nearly to the levels seen in October.
Both of these lines were restored to service shortly before the
Westine [Page 2]
Internet Monthly Report December 1986
holidays. This, coupled with the light traffic normally experi-
enced during the holidays, has resulted in the return of good net-
work performance. We will be monitoring network performance
closely as traffic returns to normal levels in January.
Finally, on December 12, the ARPANET experienced a significant
outage due to an AT&T transmission failure between Newark, NJ and
White Plains, NY. During this period, over ARPANET 30 nodes were
isolated from the Monitoring Center, and the Northeast corner of
the network became fragmented. The outage lasted approximately two
hours, and the normal operation was restored with the restoral of
the transmission facilities. This incident illustrated the fact
that common carrier communications circuits are heavily multi-
plexed, and that the trunk circuits of the ARPANET are not as spa-
tially diverse as the Logical Map of the network might suggest.
We will continue to work with DARPA and DCA to improve ARPANET per-
formance. We have made, and will continue to make, specific recom-
mendations for the enhancement of network performance, and will
report on ARPANET status, albeit more briefly, in future Internet
monthly reports.
WIDEBAND NETWORK
Problems in the Earth Station Interface at the ISI Wideband site
were corrected using ESI hardware shipped from BBN. These problems
had adversely affected the ongoing MIT-ISI NETBLT protocol experi-
ments by causing unusually high bit error rates in traffic received
from the Wideband channel at ISI.
BBN is currently investigating an equipment problem at the Lincoln
Laboratory Wideband site that is causing brief outages of local
satellite channel connectivity on a periodic basis, primarily
occurring at night.
The Wideband Butterfly Gateway software was modified to request a
higher reliability level for datagrams traversing the Wideband Net.
The stronger error-correcting code that is now being used should
result in fewer packets lost due to Wideband channel errors.
The Ft. Monmouth Wideband equipment was returned to satellite chan-
nel operations at the end of the month. It had been temporarily
de-activated due to frequent scheduled power outages caused by work
on nearby facilities.
On December 11, the Wideband Net supported a coast-to-coast IAB
meeting held via the multimedia conferencing facilities at BBN and
ISI. The meeting's packet video and packet voice traffic was sent
over the Wideband channel. The participants' reactions to their
experience were solicited to help determine which aspects of the
Westine [Page 3]
Internet Monthly Report December 1986
conferencing facility require further improvement.
BSAT software development work focused this month on continuing
design and implementation of stream scheduling synchronization
code. In addition, work on the new Butterfly Satellite Modem
Interface (BSMI) hardware progressed with delivery of the first
production run of BSMI boards to BBN.
GATEWAYS
We installed new software (Rel 3.6) in all of the Wideband But-
terfly Internet Gateways which fixed a bug that was causing them to
frequently restart. Since the new software was installed ARPA-WB,
BBN-WB, CMU-WB, ISI-WB, and MIT-WB have been very stable. MIT-WB
had a broken I/O board which was fixed. SRI-WB and RADC-WB
currently have hardware problems which are being worked on. This
was made more difficult by the holidays.
The CSS, NTA, and CNUCE Satnet gateways were very stable over the
month. RSRE was plagued by two solid hardware failures. We sent
someone to England to work on the machine who replaced two boards.
UCL was isolated by the RSRE failure.
The other Butterfly Gateways (ARPA, BBN, BBN-EN1, BBN-EN2, ISI,
MIT) were working very well during the month with only a few short
outages.
Just to show that even PDP-11's break too, the DCEC PDP-11 Gateway
also had hardware problems toward the end of the month. DEC field
service was called in to fix it. During the outage, we used EGP to
allow the UCL PDP-11 gateway to get access, via the CSS Butterfly
Gateway, to the rest of the Internet.
SATNET
We are continuing to experience some problems with channel 1
(errors and some lost hellos). We have been waiting for spare
modems from Linkabit before attempting to work on the network. In
January we will try to go ahead with the work to improve perfor-
mance on channel 1. Channel 0 has remained healthy so problems
with channel 1 have not seriously affected the overall performance
of the SATNET.
Early in the month the problems with channel 1 caused several SIMP
crashes. The SIMPs were reloaded and looped off channel 1. A long
standing bug would cause a SIMP to crash if a channel was lost for
over 30 minutes. The bug has been found and fixed. We now expect
the SIMPs to remain stable in spite of problems with channel 1.
Westine [Page 4]
Internet Monthly Report December 1986
We realize that there have been interruptions in the overall ser-
vice provided by the SATNET. There have been problems with the
gateways and some line problems between the SIMPs and the gateways.
VAX NETWORKING
In the month of December, the first successful cross-country Inter-
net multicast tests were conducted, with the 4.3bsd multicast
software running on a Microvax at Stanford University and a Vax at
BBN, and the V System multicast implementation running on Sun
workstations at Stanford.
The first beta version of the 4.3bsd multicast software (both IGMP
implementation and multicast agent) was shipped to Eric Cooper, of
Carnegie-Mellon University. Eric is supervising the porting of the
multicast software into the MACH operating system.
Survivable Radio Network (SURAN)
Since this is the first contribution from the Survivable Radio Net-
work (SURAN) project at BBN, this note will include some informa-
tion on project goals, background, etc.
The goal of SURAN is to create a large (1000s to 10,000s of nodes)
distributed network with a control structure that is capable of
surviving the loss of components, jamming and active attacks on the
network control structure.
BBNs role in SURAN to date has consisted of three main efforts: the
development of a network architecture that is capable of supporting
a very large number of nodes, the development of a security archi-
tecture that can protect control traffic and support efforts to
defend the network, and the development of a network manager which
allows the operator to display both global overviews of the network
and detailed views of specific nodes.
The network architecture that has been developed is a hierarchic
one. Nodes are organized into clusters, and clusters into super-
clusters; nodes keep track of routes to nodes in their cluster, to
clusters in their supercluster and to all superclusters in the net-
work. Protocols have been developed for clustering, for computing
routes, for forwarding packets and for address service. (Address
servers provide source nodes with the hierarchical address of a
destination node. This address is used to determine the destina-
tion cluster and supercluster and in routing the packet to its des-
tination.) While our eventual goal is to develop a network without
specialized nodes (as this is the most robust), to expedite the
research into these algorithms we have adopted an intermediate
architecture in which special hardware is used to implement
Westine [Page 5]
Internet Monthly Report December 1986
clusterheads and superclusterheads. (These nodes are used to form
the clusters and to compute and distribute the hierarchic routes.
They play no special role with respect to forwarding packets and
routes are no more likely to go through a clusterhead than through
any other node.) Most recently we have been implementing the clus-
terhead software and have been studying caching algorithms for the
address servers.
The security architecture will be responsible for protecting con-
trol traffic from unauthorized disclosure, authenticating nodes,
preventing the undetected mutilation of control traffic, and for
allowing over-the-air rekeying of nodes. We are currently in the
midst of a study which will more precisely define the requirements
of SURAN, evaluate alternative architectures and consider the
issues involved in integrating the selected security architecture
with the other SURAN protocols.
The network manager (NM) will be useful in both developmental and
operational situations as it can be used for remote debugging of
nodes and for displaying integrated views of the state of the net-
work. These views are expected to assist an operator in determin-
ing the source of problems (congestion, jamming, attacks, etc.) and
in dealing with them. The NM is currently capable of displaying
information from "old" packet radios (developed under the PRNET
project). We are currently writing software to allow the NM to
monitor the packet radios being built for the SURAN project, and
are developing AI tools to assist an operator in detecting prob-
lems.
Bob Hinden
ISI
---
Internet Concepts Project
RFC 993 was published: Clark, D., "PCMAIL: A Distributed Mail
System for Personal Computers", RFC 993, MIT, December 1986.
Greg Finn began looking into high speed fiber optic connec-
tions for ISI to nearby Universities.
Multimedia Conferencing Project
Joyce Reynolds presented a BBN Diamond Multimedia Mail demo to
Dave Taylor of Hewlett Packard December 15.
Brian Hung tested out the validity of the Multimedia messages
he had generated on the IBM-PC AT and was partially
Westine [Page 6]
Internet Monthly Report December 1986
successfull. After some modifications to the Multimedia mes-
sage format on the IBM-PC, he was able to deliver the messages
to the BBN's Diamond Multimedia System. However, the Diamond
System was unable to present the bitmap data on the Sun works-
tation. The problem is in the Multimedia Message Content Pro-
tocol generated by the IBM-PC which the Diamond System was
unable to interpret. Further tests will be conducted after
some modifications to the Multimedia messages generated by the
IBM-PC.
Brian Hung
A second bi-coastal meeting of the Internet Activities Board
was held on December 11th. The six participants at each of
the two sites ISI and BBN communicated through packet voice
and video teleconferencing for the seven-hour meeting. This
time all conference traffic was carried over the Wideband Net-
work, whereas for the previous bi-coastal meeting in August a
commercial telephone circuit carried the voice signal. The
packet voice system provided a true "4-wire circuit" between
the two sites so we were able to test different methods of
conference room echo suppression. More work is needed on the
audio system, but the participants generally agreed that the
video teleconference provided an effective and convenient
means for the group to meet.
Steve Casner
NSFNET Project
On December 16-17, Bob Braden attended a two-day meeting at
the University of Delaware on NSFNET technical and administra-
tive issues. Jon Postel and Bob Braden began work on the next
revision to the Gateway Spec RFC (RFC985).
As part of its NSFNET protocol coordination activities, we
have started looking at user-level protocol issues which are
likely to be relevant to the NSFNET user community but have
not been of interest to the Internet research community. Good
examples of such issues are background file transfer and
remote job entry. Bob Braden is preparing a draft RFC updat-
ing the ARPANET RJE protocol to match current requirements.
Annette DeSchon is building an experimental background file
transfer server on a Sun workstation. This server will allow
a user to submit a request for a reliable file transfer to
take place in the future, thus insulating the user from prob-
lems such as temporary host and network outages. The server
will allow a user to interactively specify sets of file
transfer parameters -- source and destination hosts, logins,
and file names. In addition ,the user may specify the time to
Westine [Page 7]
Internet Monthly Report December 1986
start the file transfer, the number of times to retry the
transfer, the retry interval, and a mailbox where a message
reporting the results will be sent. The actual transfer will
be performed using the third-party model of FTP (RFC959).
Bob Braden
Supercomputer and Workstation Communication Project
Alan Katz started to experiment with X-Windows and did a com-
parison of equations in Xerox Viewpoint, Interleaf, EQN/Troff,
and TEK (Alan liked EQN best).
Alan Katz
LINKABIT
-------
Multiple Satellite System (MSS)
MSS will be a global low-altitude satellite network, currently in
the preliminary design phase. The present design is for 240 satel-
lites uniformly distributed over the globe, at an altitude of about
400 NMiles. Their orbits are effectively random wrt each other as
a function of time, since they do not have station-keeping (no
onboard propulsion). Support for up to 10,000 earth terminals (ETs)
will be provided. Needless to say, MSS will be a packet switched
network supporting prioritized data and voice. The key motivation
is survivability through satellite proliferation.
The present effort involves 11 contractors for a 1-year preliminary
design effort which will end next February; Phase II, detailed
design and prototype development, is expected to start around next
August. Dual awards exist for the three major satellite hardware
elements: satellite bus is RCA and Ball; radio is Harris and Cin-
cinnati Electronics; antenna is Rockwell Anaheim and Harris. Also
under contract are Qualcomm for protocols, Spacecom and COMSAT for
system issues, and ourselves (M/A-COM Govt Systems, aka Linkabit)
as SETD.
The comm architecture which has evolved as a result of the present
and past efforts consists of a beam-hopped time-shared approach.
All satellites and ETs operate on the same frequency with a single
half-duplex transmitter and receiver. Each has an electronically
steered directional antenna (eg, phased aray), which is time-hopped
synchronously on each link. A new protocol has evolved to achieve
efficient multiple accessing, ie, which minimizes RF power and
spectrum requirements (power is the major cost driver for the
satellite). The access protocol is called ARNS (Adaptive Receive
Westine [Page 8]
Internet Monthly Report December 1986
Node Scheduling), developed by Qualcomm.
Robust link establishment and antenna pointing techniques are
planned which do not require knowledge of absolute position or
satellite motion (the satellite will use a simple gravity gradient
boom for vertical stabilization, providing a 3-sigma motion about
the nadir of about 10 degrees). The major protocol effort now get-
ting underway is in the development of a routing protocol. We are
also evaluating an autonomous position estimation approach (no
ground tracking) which could provide absolute position info if that
proves useful for routing and/or link acquisition under jamming
conditions.
Dick Binder
MIT-LCS
-------
December Report from MIT-LCS
This month we have seen more wonderful examples of the fragility of
the Internet mail system: one in which a reply with a malformed
"Cc:" field looped repeatedly between two mailers, and one in which
a malformed mailer interaction caused 157 copies of a 30 Kbyte mes-
sage to be delivered. The disk at the receiving end overflowed
when the mail file hit 16 Mbytes. Continued research into the
robustness of distributed systems is clearly justified.
Lixia Zhang
NTA & NDRE
----------
No report received.
ROCKWELL INTERNATIONAL
----------------------
Introduction
Rockwell International has participated sporadically in the
Internet Research Program during the past couple of years.
Until recently, our participation has been limited mostly to
Internet task force meetings: John Jubin participated in all
three of the Robustness and Survivability Task Force
meetings, and Jim Stevens participated in the June 1985 and
May 1986 Tactical Internet Task Force meetings. Over the
past three months, however, our participation has grown to
Westine [Page 9]
Internet Monthly Report December 1986
the point that we decided we should report our activities in
the Internet Monthly Report. Our recent activities have
consisted mostly of David Young's investigation into
Internet multicast protocols, as applied to tactical
scenarios, and Jim Stevens' design of a Transaction Transport
Protocol. These activities are described below.
Tactical Internet Multicast Protocols
This past summer, a multicast routing protocol for packet
radio networks was designed under the auspices of the
Army/DARPA Distributed Communication and Processing
Experiment (ADDCOMPE). As an outgrowth of this activity,
David Young investigated the work that was being done by the
Internet Research Group to develop a multicast capability
within the Internet. David reviewed two RFCs - RFC 966,
"Host Groups: A Multicast Extension to the Internet
Protocol", and RFC 988, "Host Extensions for IP Multicasting"
- and established DDN-mail discussion with the authors. We
assessed that these protocols would be inefficient for
limited-bandwidth, multi-hop networks such as the ARPANET and
packet radio networks, and that they would not support the
rapid forming and disbanding of multicast groups envisioned
for tactical scenarios. David suggested extensions to the
manner in which host groups are formed and deleted. In
particular, he specified the capability for a host to form a
(multicast) host group, enumerating the (initial) membership
of the group. This capability would provide for much more
efficient dissemination of the required control information
throughout the internetwork and throughout the participating
networks.
Transaction Transport Protocol (TTP)
Jim Stevens designed a transaction-oriented transport-level
protocol for the Internet which he called the Transaction
Transport Protocol (TTP). He wrote a draft RFC and made it
available to Bob Braden and the SUrvivable RAdio Networks
(SURAN) Implementers Group for preliminary review. TTP
evolved from the Simple Network Acknowledging Protocol
(SNAP), the transport-level control protocol implemented as
part of the SURAN Protocol suite.
As originally conceived, TTP would have provided features to
support client/server applications such as correlation of
server response to client request. However, while doing the
detailed design, Jim discovered that providing these special
features along with the basic transaction/message reliability
would have added complexity without supporting all of the
desired client/server application requirements - requirements
that arise, for example, from remote procedure calls or
Westine [Page 10]
Internet Monthly Report December 1986
sensor monitoring.
Thus Jim simplified the protocol down to providing the basic
services for reliable message/transaction delivery:
o message orientation, including fragmentation/reassembly
of large messages;
o reliable delivery, that is positive indication that the
message arrived at the destination without errors
(from lost, out of order, or duplicate packets, or
from packets with bit errors), and that the messages
arrived in correct sequence;
o low delay from minimum number of packets due to
piggybacking of acknowledgments and data, selective
acknowledgement, and no explicit connection setup or
teardown phases;
o TCP-port-like addresses.
Jim also described how some of the different client/server
application requirements can be provided on top of TTP.
John Jubin
SRI
---
The Functional Summary of the DARPA SURAP1 Network has been pub-
lished. This document describes the functionality of the first
protocol release - - SURAP1 (SUrvivable RAdio Protocol) of the
DARPA SURAN (SUrvivable RAdio Network) program. It describes the
physical components, features and size of the network and illus-
trates briefly how data is forwarded through the network. This
paper is intended to provide a high level description of the SURAP1
network. A large number of other papers have also been written
during the course of the SURAN program. This documentation
includes algorithm design, user guides and software specifications.
The SURAN bibliography identifies all the documentation which
currently exists for the SURAN program and briefly describes the
contents of those documents.
Janet Tornow
Westine [Page 11]
Internet Monthly Report December 1986
UCL
---
UCL has now said goodbye to Peter Lloyd, who has just finished his
PhD thesis. We wish him well in the future.
Peter has just written up his most recent work on the measurements
we have been making over the UCL-SATNET path to the US, and the
following reports are available.
Internal notes 2057,2058:
Bottleneck Tests on the UCL-Goonhilly Path
Testing for Anomalous SATNET Delays
Work has continued on protocols for distributed computing, with a
pilot implementation of the sequential exchange protocol for the
PC_IP environment. The UCL RPC mechanism now runs under several
flavours of UNIX (4.2/4.3/SysV), MS-DOS and CMOS. Interoperation
of the UDP version has been tested, but a full RPC/ESP system is
only available for Sun 4.2BSD so far.
An implementation of a high-performance low-cost ethernet-ethernet
IP bridge with per-host access control has been started. This runs
under CMOS on a Q68 (MDB) Board with a Q-Bus and two DEC Deqna eth-
ernet interfaces.
The use of PEPY as an alternative to Courier and Glue (the UCL XDR
language) is being looked at for various applications, especially
directory and authentication services. (PEPY is the presentation
specification parser from Marshall Rose's ISO-Stack implementation)
Jon Crowcroft
UNIVERSITY OF DELAWARE
----------------------
1. I continued to collaborate with Linkabit staff on the design
of the Dissimilar Gateway Protocol (DGP) for Ford Aerospace
and RADC. I designed an authentication procedure suitable for
the initial acquistion phase and distributed a draft proposal
to the task forces. I also continued working on a comprehen-
sive architecture document for DGP. Linkabit staff are working
on architectural models, state descriptions and requirements
analyses.
2. The Network Time Protocol (NTP) network has been expanded by
Westine [Page 12]
Internet Monthly Report December 1986
the addition of a new WWVB primary radio clock at the National
Center for Atmospheric Research (NCAR) in Boulder, CO. The
clock, kindly furnished by Steve Casner at ISI, is connected
to the NCAR fuzzball on the NSFNET Backbone, so that its ticks
can be heard throughout the Internet community. The two pri-
mary radio clocks that keeled last month have returned to ser-
vice, making a total of four (Vienna, VA, College Park, MD,
Dearborn, MI, and Boulder, CO).
3. A new X.25 port came up on the University of Delaware IMP for
the UDELNET swamp. Wiring was completed for an 1822 port allo-
cated to the fuzzball gateway as well. We anticipate moving
the DCNET (128.4) from Linkabit to here shortly and leaving a
new class-C net behind for Linkabit use.
4. A new gateway TERP.UMD.EDU came up between the University of
Maryland UMDNET and ARPANET using an ACC 5250 interface and
driver. I attempted to repeat the experiment reported last
month with the PSC-GW.PSC.EDU gateway at CMU, but could not
get any reliable data at all. It seems something seriously is
wrong at both sites with the interface, driver or IMP. A new
ACC 5250 interface is to be installed here shortly, so we are
very concerned to get to the bottom of this.
5. The University of Delaware hosted two NSF meetings on 16-17
December. One was attended by about two-dozen wizards from the
technical staffs of the various NSFNET Backbone sites and cam-
puses, while the other was attended by about the same number
of buzzards from the administrational and operational staffs.
The meetings proved a fine forum to air many of the issues
being faced by these creatures now and surely by many others
in the Internet community in future.
6. I attended a two-day National Academy of Sciences committee
meeting on telephone network reliability, an IAB telemeeting
at ISI and an interesting and useful meeting on gateway and
routing issues with the ANSII and Internet buzzards at SRI
International.
7. I also added a simple, UDP-based, network-statistics
query/response feature for the NSFNET fuzzballs, rebuilt the
serial device drivers for greater reliability, implemented a
Unix-compatible SLIP driver and rebuilt the kernel storage-
management system.
Dave Mills
Westine [Page 13]
Internet Monthly Report December 1986
TASK FORCE REPORTS
------------------
APPLICATIONS
No report received.
END-TO-END SERVICES
No progress to report this month.
Bob Braden
INTERNET ARCHITECTURE
1. Activity continued at a good clip on the TCP/IP and NSF-
ROUTING lists, as well as in ad-hoc exchanges, but the INARC-
TF list remained relatively quiet. A proposed authentication
scheme was distributed to the INARC-TF list for advice and
comment.
2. Current issues under discussion include the explosive growth
of the NSFNET community with the inauguration of the SURANET
and NYSERNET regional nets. These nets now provide many,
diverse paths between a surprising number of campus nets form-
erly connected only by ARPAnet and MILnet. For instance,
thirty-one campus and regional nets now share backup gateways
to the ARPANET at Cornell, Maryland, CMU and Linkabit (Vienna,
VA), as well as their own gateways. At a recent meeting of
campus network operators it was estimated that an additional
fifty networks will become operational within the next six
months. There is a crucial need to study and resolve issues in
load sharing, type-of-service routing and interoperability
with existing and proposed routing architectures and proto-
cols.
3. There were no other submissions on activity areas as requested
last month.
Dave Mills
Westine [Page 14]
Internet Monthly Report December 1986
INTERNET ENGINEERING
No report received.
INTEROPERABILITY
No progress to report this month.
Deborah Estrin
PRIVACY
During December, John Linn distributed a revised draft of the
Privacy Task Force's RFC, "Privacy Enhancement for Internet
Electronic Mail: Part I: Message Encipherment and Authentica-
tion Procedures" to the task force membership for final review
prior to dissemination to the Internet community.
John Linn
ROBUSTNESS AND SURVIVABILITY
No report received.
SCIENTIFIC COMPUTING
No report received.
SECURITY
No report received.
TACTICAL INTERNET
No report received.
Westine [Page 15]
Internet Monthly Report December 1986
TESTING AND EVALUATION
No report received.
Westine [Page 16]