~
April 1992
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 participating organizations.
This report is for Internet information purposes only, and is not
to be quoted in other publications without permission from the
submitter.
Each organization 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 network mail to:
Ann Westine Cooper (Cooper@ISI.EDU)
NSF Regional reports - Corinne Carroll (ccarroll@NNSC.NSF.NET)
Directory Services reports - Tom Tignor (TPT2@ISI.EDU)
Requests to be added or deleted from the Internet Monthly report list
should be sent to "cooper@isi.edu".
Back issues of the Internet Monthly Report can be copied via FTP:
FTP> nis.nsf.net
Login: anonymous guest
ftp> cd publications/internet.monthly.report
ls
get IMRYY-MM.TXT
For example, JUNE 1991 is in the file IMR91-06.TXT.
Cooper [Page 1]
Internet Monthly Report April 1992
TABLE OF CONTENTS
INTERNET ACTIVITIES BOARD
IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . page 4
INTERNET RESEARCH REPORTS . . . . . . . . . . . . . . . . page 5
AUTONOMOUS NETWORKS . . . . . . . . . . . . . . . . . page 5
END-TO-END SERVICES . . . . . . . . . . . . . . . . . page 5
PRIVACY AND SECURITY . . . . . . . . . . . . . . . . . page 5
RESOURCE DISCOVERY AND DIRECTORY SERVICE . . .. . . . page 7
INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 7
Internet Projects
BARRNET . . . . . . . . . . . . . . . . . . . . . . . . . page 11
BOLT BERANEK AND NEWMAN, INC., . . . . . . . . . . . . . page 11
CIX (COMMERCIAL INTERNET EXCHANGE). . . . . . . . . . . . page 12
CSUNET (CALIFORNIA STATE UNIVERSITY NETWORK). . . . . . . page 13
ISI . . . . . . . . . . . . . . . . . . . . . . . . . . . page 15
JVNCNET . . . . . . . . . . . . . . . . . . . . . . . . . page 17
LOS NETTOS . . . . . . . . . . . . . . . . . . . . . . . page 19
MERIT/MICHNET . . . . . . . . . . . . . . . . . . . . . . page 19
NEARNET (NEW ENGLAND ACADEMIC AND RESEARCH NETWORK) . . . page 21
NNSC, UCAR/BOLT BERANEK and NEWMAN, INC., . . . . . . . . page 22
NORTHWESTNET. . . . . . . . . . . . . . . . . . . . . . . page 22
NSFNET/ANSNET BACKBONE ENGINEERING. . . . . . . . . . . . page 23
NSFNET/INFORMATION SERVICES . . . . . . . . . . . . . . . page 31
SAIC. . . . . . . . . . . . . . . . . . . . . . . . . . . page 32
SDSC (SAN DIEGO SUPERCOMPUTER CENTER) . . . . . . . . . . page 33
SRI . . . . . . . . . . . . . . . . . . . . . . . . . . . page 35
UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 36
UDEL. . . . . . . . . . . . . . . . . . . . . . . . . . . page 37
WISCNET . . . . . . . . . . . . . . . . . . . . . . . . . page 38
DIRECTORY SERVICES ACTIVITIES
DIRECTORY SERVICES MESSAGE . . . . . . . . . . . . . . . page 39
PSI DARPA/NNT X.500 PROJECT . . . . . . . . . . . . . . . page 39
PSI WHITE PAGES PILOT . . . . . . . . . . . . . . . . . . page 40
REGISTRATION AUTHORITY COMMITTEE (ANSI USA RAC) . . . . . page 40
SG-D MHS-MD . . . . . . . . . . . . . . . . . . . . . . . page 42
USENET-ADDRESSES DATABASE . . . . . . . . . . . . . . . . page 47
CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 48
Cooper [Page 2]
Internet Monthly Report April 1992
IAB MESSAGE
STANDARDS ADVANCES
The following list shows the protocol standards actions approved by
the IAB since April 1, 1991.
o Mapping between X.400(1988)/ISO 10021 and RFC-822
Proposed Standard 7 Apr 1992
RFC in Preparation
o Downgrading X.400(1988) to X.400(1984)
Proposed Standard 7 Apr 1992
RFC in Preparation
o PPP -- Point-to-Point Protocol (new version)
Proposed Standard: 10 April 1992
RFC in Preparation
Although this new version of PPP has changes substantial
enough to warrant return to Proposed State, it is
essentially backwards-compatible with the Draft Standard
(RFC-1171) that it replaces. The specification RFCs were
also re-packaged, so RFC-1172 (PPP-INIT) was also obsoleted.
NEW RFC's
The following RFC's were published in April, in accordance with
decisions reported previously.
o NetFAX -- A File Format for the Exchange of Images
Proposed Standard: 17 March 1992
RFC-1314 - "A File Format for the Exchange of Images
in the Internet"
o Frame Relay MIB
Proposed Standard: 17 March 1992
RFC-1315 - "Management Information Base for Frame
Relay DTEs"
o Character Stream Device MIB
Proposed Standard: 17 March 1992
RFC-1316 - "Definitions of Managed Objects for Character
Stream Devices"
Cooper [Page 3]
Internet Monthly Report April 1992
o RS-232 MIB
Proposed Standard: 17 March 1992
RFC-1317 - "Definitions of Managed Objects for
RS-232-like Hardware Devices"
o Parallel Printer MIB
Proposed Standard: 17 March 1992
RFC-1318 - "Definitions of Managed Objects for Parallel-
Printer-like Hardware Devices"
o NTP-3 -- Network Time Protocol Version 3
Proposed Standard: 4 September 1991
RFC-1305 - "Network Time Protocol (Version 3)
Specification, Implementation, and Analysis"
Bob Braden (Braden@ISI.EDU)
INTERNET RESEARCH REPORTS
-------------------------
AUTONOMOUS NETWORKS
-------------------
No internet-related progress to report.
Deborah Estrin (Estrin@USC.EDU)
END-TO-END SERVICES
-------------------
No internet-related progress to report.
Bob Braden (Braden@ISI.EDU)
PRIVACY AND SECURITY
--------------------
The Privacy and Security Research Group (PSRG) met at the
University of Wisconsin (Madison) April 29-May 1. The focus of
the meeting was continued work on a series of documents which
will provide a framework for an Internet security architecture.
Prior to the meeting a draft book chapter on network security
architecture was distributed for comment and as background
reading. A draft outline of the document was developed and
writing assignments were made. The outline follows:
Cooper [Page 4]
Internet Monthly Report April 1992
1. Overview
A discussion of the document sections, overall rationale, plans
for use relative to standards track RFCs in the future, etc.
Definitions of vulnerability, attacks, and threat. Motivations
for better Internet security because of changing threat
environment. The role of risk analysis. Philosophy for
internet security standards:
1.1 Security Services
Review of ISO 7498-2, plus service availability. More
discussion of services and examples.
1.2 Security Mechanisms
General principles of "good" security mechanisms, starting with
Kent book chapter, including the ability to implement in a
fashion which promotes ease of use. Both general and per-
mechanism class principles will be addressed. ISO 7498-2
mechanisms as starting point, plus more details, additional
mechanism classes, and examples.
1.3 Service/Layer Map
Based on ISO 7498-2 Table 2, plus SILS work and service
availability. Includes service layering rationale.
1.4 Service/Mechanism Map
ISO 7498-2 Table 1, expanded based on section 1.3, plus
rationale.
1.5 Application/Service/Mechanism Discussion
For major classes of Internet applications, describe the
standard protocols used to implement the application in TCP/IP
and OSI suites. Discuss each security service in a subsection
explaining why the service is appropriate. Recommend a specific
mechanism, if available, perhaps on a per-protocol basis.
Applications include: directory (X.500 & DNS), message handling
(X.400 & SMTP), time (NTP III), network management (SNMP &
CMIP), Interactive (Telnet, VT, X windows), file transfer (FTP &
VTAM), exterior gateway protocols (EGP, BGP & IDRP), interior
gateway protocols (OSPF, IS-IS), etc.
Cooper [Page 5]
Internet Monthly Report April 1992
1.6 Security Mechanism Catalog
Discuss specific examples of basic security mechanisms
(encipherment, digital signature, hashing, authentication
exchanges, key management, security labels, ...). Examine
standard security protocols (SILS, NLSP, TLSP, PEM, X.411,
X.509, ...) for use with TCP/IP and OSI suites.
Steve Kent <kent@BBN.COM>
RESOURCE DISCOVERY AND DIRECTORY SERVICE
----------------------------------------
No progress this month.
Mike Schwartz@latour.cs.colorado.edu.
INTERNET ENGINEERING REPORTS
----------------------------
1. The next IETF meeting, co-hosted by MIT and NEARNet, will
take place from July 13th through the 17th in Cambridge,
Massachusettes. The Sunday night reception will be held at
the Hyatt Regency Cambridge begining at 6 PM on July 12th.
Complete registration and logistics information has already
been mailed to the IETF mailing list. For copies of this
information (or for any other question about the upcoming
meeting), please mail your request to
"ietf-rsvp@nri.reston.va.us".
Based on input and suggetions received, there will be a
slightly different meeting agenda in Cambridge, specifically
to provide more meeting slots for Working Groups and BOFs.
Additionally, technical presentations will be spread across
the week in the mornings.
2. Looking ahead, the Fall IETF is scheduled for November 16-20,
1992 in Washington, DC. Our local host is U.S. Sprint. The
Spring 1993 IETF will be held in Columbus, Ohio, March 28th -
April 2nd. Our Local Hosts will be OARnet and The Ohio State
University.
3. The IESG received two requests to approve the publication of
the following Internet Drafts:
a. Multiprotocol Interconnect on X.25 and ISDN in the Packet
Mode to Proposed Standard.
Cooper [Page 6]
Internet Monthly Report April 1992
b. "An Architecture for Inter-Domain Policy Routing" and
"Inter-Domain Policy Routing Protocol Specification and
Usage: Version 1" to Proposed Standard.
The IESG also received a request from the Privacy Enhanced Mail
Working Group to move RFC's 1113, 1114 and RFC 1115, currently
Draft Standards, to Historical Standard Status. These documents
no longer reflect current PEM protocols.
Last call notifications for all three requests were sent to the
IETF mailing list by the IESG Secretary.
4. The IESG made the following recommendations to the IAB during
the month of April, 1992:
a. PPP Link Quality Monitoring be published as a Proposed
Standard.
b. MIME (Multipurpose Internet Mail Extensions) and
Representation of Non-ASCII Text in Internet Message
Headers be published jointly as a Proposed Standard.
5. The following three Working Groups were created during the
month of April:
SNMP over a Multi-protocol Internet (mpsnmp)
MIME-MHS Interworking (mimemhs)
TCP Client Identity Protocol (ident)
6. The following two Working Groups were concluded during the
month of April:
OSI Internet Management (oim)
Special Host Requirements (shr)
7. 33 Internet Draft Actions were taken between April 1 and 30,
1992: (Revised draft (o), New Draft (+) )
WG I-D Title <Filename>
------ ---------------------------------------------------
(idpr) o An Architecture for Inter-Domain Policy Routing
<draft-ietf-idpr-architecture-04.txt,.ps>
(osids) o Naming Guidelines for Directory Pilots
<draft-ietf-osids-dirpilots-05.txt, .ps>
(822ext) o MIME (Multipurpose Internet Mail Extensions):
Mechanisms for Specifying and Describing the
Format of Internet Message Bodies
<draft-ietf-822ext-messagebodies-06.txt,.ps>
Cooper [Page 7]
Internet Monthly Report April 1992
(822ext) o A User Agent Configuration Mechanism For
Multimedia Mail Format Information
<draft-ietf-borenstein-configmech-04.txt,.ps>
(pem) o The MD5 Message-Digest Algorithm
<draft-rsadsi-rivest-md5-02.txt>
(pem) o The MD2 Message-Digest Algorithm
<draft-rsadsi-kaliski-md2-01.txt>
(pem) o The MD4 Message-Digest Algorithm
<draft-rsadsi-rivest-md4-01.txt>
(smtpext) o SMTP Extensions for Transport of Enhanced
Text-Based Messages
<draft-ietf-smtpext-8bittransport-04.txt>
(pppext) o PPP Authentication Protocols
<draft-ietf-pppext-authentication-03.txt>
(ripv2) o RIP Version 2 Carrying Additional Information
<draft-ietf-malkin-rip-02.txt>
(x25mib) o SNMP MIB extension for LAPB
<draft-ietf-x25mib-lapbmib-02.txt>
(x25mib) o SNMP MIB extension for MultiProtocol Interconnect
over X.25
<draft-ietf-x25mib-ipox25mib-02.txt>
(x25mib) o SNMP MIB extension for the X.25 Packet Layer
<draft-ietf-x25mib-x25packet-02.txt>
(bgp) o BGP OSPF Interaction
<draft-ietf-bgp-ospfinteract-06.txt>
(osids) o A String Representation of Distinguished Names
<draft-ietf-osids-distnames-02.txt, .ps>
(osids) + Counting the Directory Information Tree
<draft-ietf-osids-dirtree-00.txt, .ps>
(ripv2) + RIP Version 2 MIB Extension
<draft-ietf-ripv2-mibext-00.txt>
(mhsds) + Representing Tables and Subtrees in the Directory
<draft-ietf-mhsds-subtrees-00.txt, .ps>
(mhsds) + Representing the O/R Address hierarchy in the
Directory Information Tree
<draft-ietf-mhsds-infotree-00.txt, .ps>
(mhsds) + Use of the Directory to support mapping between
X.400 and RFC 822 Addresses
<draft-ietf-mhsds-supmapping-00.txt, .ps>
(mhsds) + MHS use of the Directory to support distribution
lists
<draft-ietf-mhsds-mhsuse-00.txt, .ps>
(mhsds) + Use of the Directory to support routing for RFC 822
and related protocols
<draft-ietf-mhsds-822dir-00.txt, .ps>
(mhsds) + A simple profile for MHS use of Directory
<draft-ietf-mhsds-mhsprofile-00.txt, .ps>
Cooper [Page 8]
Internet Monthly Report April 1992
(mpsnmp) + SNMP over OSI
<draft-ietf-mpsnmp-overosi-00.txt>
(none) + Supernetting: an Address Assignment and
Aggregation Strategy
<draft-fuller-supernet-00.txt>
(ident) + Ident MIB
<draft-ietf-ident-MIB-00.txt>
(none) + Physical Link Security Type of Service
<draft-eastlake-linksectos-00.txt>
(mhsds) + MHS use of Directory to support MHS Routing
<draft-ietf-mhsds-routdirectory-00.txt,.ps>
(osids) + Lightweight Directory Access Protocol
<draft-ietf-osids-lightdirect-00.txt>
(ospf) + Proposed modifications to RFC 1247
<draft-ietf-ospf-v2update-00.txt>
(none) + A Revision to IP Address Classifications
<draft-solensky-csharp-00.txt>
(idpr) + IDPR as a Proposed Standard
<draft-ietf-idpr-summary-00.txt, .ps>
8. Eight RFC's based on IETF WG activity were produced during the
month of April, 1992.
RFC Status WG Title
------- -- -------- ----------------------------------------
RFC1314 PS (netfax) A File Format for the Exchange of Images
in the Internet
RFC1315 PS (iplpdn) Management Information Base for Frame
Relay DTEs
RFC1316 PS (charmib) Definitions of Managed Objects for
Character Stream Devices
RFC1317 PS (charmib) Definitions of Managed Objects for
RS-232-like Hardware Devices
RFC1318 PS (charmib) Definitions of Managed Objects for
Parallel-printer-like Hardware Devices
RFC1319 I (pem) The MD2 Message-Digest Algorithm
RFC1320 I (pem) The MD4 Message-Digest Algorithm
RFC1321 I (pem) The MD5 Message-Digest Algorithm
Steve Coya (scoya@@NRI.RESTON.VA.US)
Phill Gross (pgross@NRI.RESTON.VA.US)
Cooper [Page 9]
Internet Monthly Report April 1992
INTERNET PROJECTS
-----------------
BARRNET
-------
Four 56kbps connections including one high school and six low-speed
BARRNet Remote Affiliate Members were added in April. An FDDI ring
was installed and activated connecting all BARRNet core routers at
Stanford to the ENSS, so that all traffic going over the T3
connection to the NSFNET is no longer restricted by an Ethernet
path. Also OSPF is now operating on most of the cisco routers in
BARRNet's core.
Paul Baer <baer@jessica.stanford.edu>
BOLT BERANEK AND NEWMAN INC.
----------------------------
IDPR
During the month of April, the request for IETF proposed standard
status of IDPR was made public. Since that time we have been
answering questions and responding to comments posed in response to
the announcement and to critical review of the IDPR documents. We
have also been coordinating with the sites that will be
participating in pilot demonstrations of IDPR later this summer.
ST Conferencing
During April, a total of 8 video conferences and 1 SIMNET exercise
was conducted. Three of the conferences involved three sites, and
5 involved 2 sites. ALSP and DSI groups were the main conferencing
users. Although the scheduled conference usage was low, the
overall network usage was not, as new installations, software, and
demonstrations during April precipitated near-daily test
conferences.
We continued testing the ST priority packet fix on the UK Fatpipe
during April and ran several successful US/UK test conferences. We
expect to deploy this software at other locations where limited
network bandwidth may be an issue.
Most conferencing sites were converted from IBM PC-based framing
adaptors to SPC adaptors during this month. The SPCs are smaller,
less expensive, and more reliable than the PC converters, and
should improve the overall success rate of video conferences.
Because of scheduled demos and site contact schedule conflicts,
Cooper [Page 10]
Internet Monthly Report April 1992
LANL, WPC, and Frankfurt conferencing sites are not yet upgraded.
To allow SPC and PC sites to conference during this interim period,
they will connect through a patch codec at BBN. Also during this
interim period, SPC sites will only participate in 2-way
conferences. We expect to field floor control software, which will
allow SPC sites to participate in multicast conferences, during
May.
Hurlburt Field in Florida was installed as a new video conferencing
site in April. Conferencing gateways were also installed at MITRE
in Virginia, and at ESD in Massachusetts, although the site VTC
suites are not yet available. Ft. Leavenworth and one of BBN's two
conference rooms have been converted to demonstration sites for
secure conferencing. This demonstration project uses E3 encryption
units and dual gateways (one secure and one not secure) at each
site. Demonstrations are scheduled for May.
Jil Westcott <westcott@bbn.com>
CIX (COMMERCIAL INTERNET EXCHANGE)
----------------------------------
The following report outlines CIX-WEST usage for the month of
April, 1992.
----
CIX In Out
Member Octets Packets Errors Octets Packets Errors
-------- ---------------------------- ----------------------------
AlterNet 34978344081 142622862 1502 12071116975 88083082 0
CERFnet 14326796503 84974445 1426 17188189453 87112915 0
PSINet 13073521657 94602425 1 33243852908 149922427 0
Starting: Mar 31 1992 at 23:50
Ending: Apr 30 1992 at 13:35
SNMP Polling Intervals: 2798
SNMP Polling Frequency: 15 minutes
In - traffic entering the CIX from the CIX member network
Out - traffic exiting the CIX into the CIX member network
-----
At the present time, approximately 570 networks within AlterNet,
CERFNet, and PSINet are using the CIX-WEST.
Cooper [Page 11]
Internet Monthly Report April 1992
A complete list of networks accessible via the CIX is available via
anonymous FTP from cix.org in the file cix.nets. The current
revision of this list is: 9-APR-1992.
Send mail to info@cix.org for information regarding the CIX.
Mark Fedor (fedor@uu.psi.com)
CSUNET (THE CALIFORNIA STATE UNIVERSITY NETWORK)
-----------------------------------------------
One of the most notable CSUnet activities during the last two
months has been focused on connectivity for the K-14 and university
institutions. Quotation from the Pacific Bell Press Release dated
May 6, 1992 follows:
CALIFORNIA STATE UNIVERSITY AND PACIFIC BELL
TO COOPERATE IN BUILDING EDUCATIONAL NETWORK
The California State University system and Pacific Bell have agreed
to cooperate in bringing the benefits of the Information Age to
education in California.
The plan focuses on exploring how advances in telecommunications
can be used to help fulfill the educational mission of schools
serving grades K-14, as well as the CSU's 20 institutions.
One of the first cooperative projects may involve CSU's
participation in the Knowledge Network Gateway, a service being
planned by Pacific Bell to provide California's schools with online
access to the National Science Foundation's Internet as well as to
other worldwide databases.
"California's future depends on our ability to educate our citizens
to take their places in an information-based society," said CSU
Chancellor Barry Munitz. "This requires that students have access
to computing resources, libraries, databases and instructional
technologies which may lie beyond the boundaries of individual
schools, communities, or states. Through this cooperative effort,
we hope to provide equity of access to the resources needed by
California students to meet the demands of the future."
The plan calls for developing a statewide voice, data and video
network to connect all of California's educational institutions to
Information Age learning resources. The effort will integrate
Pacific Bell's public switched network with CSU's existing
telecommunications infrastructure which provides the long distance
connections, and capitalize on advances being made by Pacific Bell
Cooper [Page 12]
Internet Monthly Report April 1992
in broadband networking technology.
Other goals of the cooperative effort include:
-- Jointly pursuing a technological solution that
facilitates student and faculty access to the National
Research and Educational Network (NREN) via CSUnet.
-- Jointly seeking support for public interest solutions and
affordable access.
-- Jointly seeking funds from government in general, and the
National Science Foundation in particular, to facilitate
provisioning of NREN connectivity to California schools.
-- Actively seeking the participation of other interested
parties, particularly those in the private sector, who
also want to help ensure equitable access to the
educational resources needed for Californians to be
competitive.
"This joint effort is very much like a part of Pacific Bell's
Knowledge Network vision, in which all educational institutions in
the state would be linked through the public network," said Pacific
Bell Executive Vice President Bob Lee. "Simply stated, we're
talking about an electronic highway of information, connecting
every school from kindergarten through university.
"Through cooperative efforts like this one with CSU, we believe
that educational applications and the infrastructure required to
support them can be developed in ways that benefit all of the
state's students," Lee said.
Pacific Bell is currently involved in a number of Knowledge Network
projects with both the California State University and University
of California systems.
With CSU, the company is engaged in distance learning activities at
Bakersfield, Chico, Dominguez Hills and San Luis Obispo. In
addition, the company entered into a cooperative agreement with CSU
San Marcos last year to develop an advanced telecommunications
platform to enable the university to be a model campus for the
Information Age.
With UC, the company is involved in Integrated Services Digital
Network (ISDN) applications development and the testing of high
speed transmission using a new technology called Frame Relay. Both
projects are underway at the UC Berkeley campus.
Cooper [Page 13]
Internet Monthly Report April 1992
The CSU is the largest system of senior higher education in the
nation. Its 20 campuses and nine off-campus centers stretch from
Arcata in the far north to San Diego in the south. Currently,
there are 361,000 students attending CSU campuses. The CSU
produces 70 percent of the state's public school teachers; 50
percent more business graduates and more computer scientists and
engineers than all other California universities and colleges
combined.
CSUnet is the wide-area network of the California State University,
interconnecting the 20 campuses and their five off-site centers
with information resources around the world.
Pacific Bell is a subsidiary of Pacific Telesis Group, a
diversified worldwide telecommunications corporation based in San
Francisco.
Mike Marcinkevicz (mdm@CSU.net)
ISI
---
GIGABIT NETWORKING
Infrastructure
Joyce Reynolds attended the RARE WG3 meetings in London, 22-24
April, and the RIPE meetings in Amsterdam, 27-29 April, 1992. Jon
Postel hosted a DARTNET meeting at ISI April 13th. Bob Braden
attended a "Workshop on Quality of Service Issues in High Speed
Networks" in Summit, New Jersey, at AT&T and chaired a halfday
session on "Specific Scheduling and Traffic Management Algorithms".
11 RFCs were published this month.
RFC 1307: Young, J., and A. Nicholson, "Dynamically Switched
Link Control Protocol", Cray Research, Inc, March 1992.
RFC 1312: Nelson, R., (Crynwr Software), and G. Arnold, (SUN
Microsystems), "Message Send Protocol 2", April 1992.
RFC 1313: Partridge, C., "Today's Programming for KRFC AM 1313
Internet Talk Radio", BBN, April, 1992.
RFC 1314: Katz, A., D. Cohen, "A File Format for the Exchange
of Images in the Internet", ISI, April 1992.
Cooper [Page 14]
Internet Monthly Report April 1992
RFC 1315: Brown, C., (Wellfleet), F. Baker, and C. Carvalho
(ACC), "Management Information Base for Frame Relay
DTEs", April 1992.
RFC 1316: Stewart, B., "Definitions of Managed Objects for
Character Stream Devices", Xyplex, Inc., April 1992.
RFC 1317: Stewart, B., "Definitions of Managed Objects for
RS-232-like Hardware Devices", Xyplex, Inc.,
April 1992.
RFC 1318: Stewart, B., "Definitions of Managed Objects for
Parallel-printer-like Hardware Devices", Xyplex, Inc.,
April 1992.
RFC 1319: Kaliski, B., "The MD2 Message-Digest Algorithm", RSA
Laboratories, April 1992.
RFC 1320: Rivest, R., "The MDA Message-Digest Algorithm",
MIT and RSA Data Security, April 1992.
RFC 1321: Rivest, R., "The MD5 Message-Digest Algorithm",
MIT and RSA Data Security, April 1992.
Ann Westine Cooper (Cooper@ISI.EDU)
MULTIMEDIA CONFERENCING
DARTnet experimentors conducted a demonstration of traffic control
algorithms on April 13th. ISI participated in demonstrations of
both ST-II and UDP/IP multicast styles of teleconferencing. For
the ST-II demo, the Multimedia Conference Control program (MMCC)
was used to orchestrate packet audio and video sessions among
groups of participants using the Host Control Protocol to
communicate connection control information to the Voice Terminal
(VT) and the Packet Voice Program (PVP). Once established, ST data
flows were bombarded with large amounts of competing traffic in an
effort to show that the Virtual Clock traffic control mechanism
protects against the degradation of real-time data delivery. PVP
was also operated in UDP/IP multicast mode for demonstrations of
traffic control algorithms implemented by MIT and LBL.
Eve Schooler presented a paper, "An Architecture for Multimedia
Connection Management", at Multimedia '92, the IEEE ComSoc 4th
International Workshop on Multimedia Communications, Monterey, CA.
Steve Casner, Eve Schooler, (casner@ISI.EDU, schooler@ISI.EDU)
Cooper [Page 15]
Internet Monthly Report April 1992
JVNCNET
-------
I. General information
A. How to reach us:
1-800-35-TIGER (from anywhere in the United States)
by e-mail
NOC: noc@jvnc.net
Service desk: service@jvnc.net
by mail: U.S. mail address:
Princeton University
B6 von Neumann Hall
Princeton, NJ 08544
(Director: Sergio Heker)
B. Hours
NOC: 24 hours/day, seven days a week
Service desk: 9:00 to 5:00 pm, M - F (except holidays)
C. Other info available on-line from NICOL
Telnet to nicol.jvnc.net.
Login ID is nicol and no password.
D. RFCs on-line
To obtain RFCs from the official JvNCnet repository
(two methods):
1) ftp jvnc.net; username: anonymous;
password: <your email address>
2) RFC automailer
Send email to sendrfc@jvnc.net. Subject line is RFCxxxx.
xxxx represents the RFC number. RFCs with three digits
only need three digits in the request.
II. New Information
Availability for March 1992 is 99.87%.
Traffic rose 6% (total incoming and outgoing packets:
1,776,331,300) compared to February 1992's traffic of
1,677,960,900 total incoming and outgoing packets).
Cooper [Page 16]
Internet Monthly Report April 1992
A. New on-line members (fully operational March, April, May 1992)
American Cyanamid, Princeton, NJ
College of St. Elizabeth, Morristown, NJ
Rhode Island College, Providence, RI
Multilingual Technologies, Fairfield, NJ
Taylor Technologies, Princeton, NJ
Roselle Borough School District, Roselle, NJ
South Brunswick School District, Monmouth Junction, NJ
Stanger, Michaelson, Spivak, and Wallace, Red Bank, NJ
Netquest Corp., Mt. Laurel, NJ
West Windsor-Plainsboro School District, Plainsboro, NJ
Unisoft, Marlboro, NJ
Hoechst-Celanese, Summit, NJ
Mier Communications, Princeton Junction, NJ
B. JvNCnet Symposium Series
For information about planned JvNCnet symposiums, please
send email to "symposium@jvnc.net" or call 1-800-35-TIGER.
C. JvNCnet K-12 Dial-up Connectivity Program
For information about the JvNCnet K-12 activities, send
email to K-12-request@jvnc.net or contact Rochelle Hammer
at 1-800-35-TIGER, option 0 (zero). JvNCnet actively works
with the teachers in the following areas: training on the
Dialin'Tiger service, development of a student user manual,
identification and sharing with teachers appropriate and
interesting applications and resources for various
grade-levels, and evaluating curriculum enhancements.
D. MEGABYTES newsletter
The next issue of Megabytes will be mailed out in about two
weeks. To subscribe to the electronic distribution of
Megabytes, send email to "megabytes-request@jvnc.net".
E. Miscellaneous
JvNCnet will have a booth at the next INTEROP in
Washington, DC on May 20-22, 1992. New and exciting
services and applications will be demonstrated.
Rochelle Hammer (hammer@jvnc.net)
Cooper [Page 17]
Internet Monthly Report April 1992
LOS NETTOS
----------
AGS plus routers are being installed at all Los Nettos sites.
Walt Prue (Prue@ISI.EDU)
MERIT/MICHNET
-------------
Merit has undergone some internal reorganization in the past few
months. Partly because of staff changes at the University of
Michigan, where Merit is housed, and partly out of Merit's strong
commitment to improving service to our customers, Merit has
reorganized into three main divisions. Each group primarily focuses
on one of our major client bases: the NSFNET backbone project,
MichNet, and the University of Michigan's UMnet project.
Jeff Ogden is now the Merit Associate Director for MichNet.
Previously Jeff was manager of recruitment and technical support
for Merit. The NSFNET Information Services group and the MichNet
Technical Support group have been combined into the Network
Information Services group, managed by Ellen Hoffman, formerly
assistant to Merit's President.
John Vollbrecht is the new Manager of the MichNet Engineering
group, which includes the software engineers previously managed by
Mark Knopper. Mark, a long-time Merit employee, has taken over the
management of Merit's Internet Engineering group, which focuses on
national networking activities. Jim Williams, formerly from the
University of Nevada at Las Vegas and NevadaNet, is the new
National Networking Associate Director.
Scott Gerstenberger, who was Associate Director for both MichNet
and the University of Michigan's data networking activities, is now
directing almost all of his efforts to U-M activities as Associate
Director for UMnet. Scott now reports to U-M's new Director of
Network Systems, Mike McGill. McGill comes to U-M from Ameritech,
Inc.
CIESIN, the Consortium for International Earth Science Information
Network, has joined Merit as an affiliate. The CIESIN facility on
the campus of Saginaw Valley State University will be linked to the
network at 1.5 million bits per second (T1), its Ann Arbor facility
will be linked at 56 thousand bits per second. (For a complete
discussion of CIESIN and its projects, see the May-June, 1991 issue
of the MichNet News.)
Cooper [Page 18]
Internet Monthly Report April 1992
The first Merit K-12 affiliate was connected to the network in late
April. Page Middle School in Madison Heights (Lamphere School
District) is the first k12 school in Michigan with a direct
connection to MichNet. This summer, we will add Northville,
Mumford, Model High, and Walled Lake -- as part of Merit Project
Connect.
This spring the MichNet dial-in service in Traverse City was
upgraded to include triple speed modems, which answer at 1200,
2400, and 9600 bits per second. As a result of this upgrade, 300
bps service in Traverse City was discontinued. The Traverse City
phone number remains the same. This upgrade was made possible by a
joint effort of the Northwestern Michigan Council of Governments,
Northwestern Michigan College, and Merit.
The Great Lakes Environmental Research Laboratory in Ann Arbor is
attaching to MichNet. GLERL, which is part of the National Oceanic
and Atmospheric Administration of the U.S. Dept. of Commerce, will
be connected at 56 kilobits per second using a pair of cisco
routers.
Merit programmers have written a packet driver for NCSA Telnet
version 2.3 which allows the use of Point-to-Point Protocol (PPP)
with NCSA Telnet for DOS machines. The package includes a telnet
client and an ftp server. The package does not include a TN3270
client.
The PPP packet driver allows NCSA Telnet to be used over
asynchronous serial connections including the MichNet public dial-
in lines. (For an introduction to PPP, see the September, 1991,
issue of the MichNet News.) This packet driver and the MichNet-
customized telnet client can be obtained via anonymous FTP fromthe
host merit.edu. The name of the file is: /pub/ppp/ncsappp.zip.
This compressed file contains the PPP packet driver, the NCSA
Telnet software, some basic configuration files, and documentation
for all of these. There is also a basic instruction file to help
you install the driver for use with NCSA Telnet. To uncompress the
entire file you will need to have the pkunzip software, version
1.1.
Questions about the PPP packet driver can be directed to:
info@merit.edu
Pat McGregor <patmcg@merit.edu>
Cooper [Page 19]
Internet Monthly Report April 1992
NEARNET (NEW ENGLAND ACADEMIC AND RESEARCH NETWORK)
---------------------------------------------------
NEARnet Membership
As of April 31, NEARnet has grown to 133 members.
NEARnet K-12 Workshop
As part of the follow-up activities from the NEARnet K-12 Workshop
in March, the NEARnet staff continues to disseminate information
distributed at the workshop. The workshop was held in cooperation
with the Massachusetts Telecomputing Coalition in an effort to
develop innovative educational partnerships between NEARnet and the
educators and administrators from the kindergarten through twelve
grade educational community in New England.
The NEARnet Staff also maintains a mailing list for discussing K-12
educationalnetworking in New England. If you would like to have
your name added to the nearnet-k12 mailing list, please send your
request to nearnet-us@nic.near.net.
NEARnet Technical and User Seminars '92
NEARnet has announced the newly revised seminar program for 1992.
Based on member feedback received at the last Technical and User
Seminar, NEARnet is offering six mini-seminars in 1992. They will
be held afternoons from 1:00 p.m.to 4:00 p.m. at Newman Auditorium
at Bolt Beranek and Newman Inc. (BBN) in Cambridge, Massachusetts.
The mini-seminars will cover specific topics of interest to
technical liaisons, information liaisons, and administrators.
Information on the seminar series is available via anonymous file
transfer (FTP) from the nic.near.net computer in the directory
seminars. Files include an announcement of the seminar series, a
copy of the registration form, information on the location and
directions to the seminars.
If you have any questions regarding the seminars, please call the
NEARnet Hotline at (617) 873-8730 or send electronic mail to the
NEARnet User Services Staff at nearnet-us.nic.near.net.
Cooper [Page 20]
Internet Monthly Report April 1992
NEARnet This Month
The April issue of the electronic bulletin "NEARnet This Month" has
been distributed. Past issues of the bulletin are available via
anonymous FTP at nic.near.net, in the directory
newsletters/nearnet-this-month.
Corinne Carroll <ccarroll@nic.near.net>
NNSC, UCAR/BOLT BERANEK and NEWMAN, INC.
----------------------------------------
The NNSC has published and distributed the latest issue of the NSF
Network Newsletter. A PostScript version of the revised newsletter
map is available via anonymous FTP at nnsc.nsf.net with the
pathname nsfnet/nsfmap.ps. The sitelist for the map is under the
pathname nsfnet/sites.
Due to an article featured in the April 27th issue of MACWEEK
Magazine, entitled "What is happening to the Internet?", the NNSC
Staff has received a tremendous amount of requests for information
on the "Tour of the Internet" and general NSFNET/Internet
information packages.
Corinne Carroll <ccarroll@nnsc.nsf.net>
NORTHWESTNET
------------
The NorthWestNet Network Engineering Advisory Board met recently to
address matters of network engineering, infrastructure, operation
and technical servicedelivery. During their April 17 meeting, the
Board reviewed scheduled maintenance, redundant connectivity
options including the availability of switched 56K and T1 services
in Pacific Northwestern metropolitan areas, Frame Relay and SMDS
service availability, collocation agreements with
telecommunications providers, and escalation procedures for problem
reporting and resolution of outages.
Carol Brand, NorthWestNet's Educational Services Specialist,
recently attended a presenter's workshop on the National Education
Supercomputer (NES) at Lawrence Livermore National Laboratory. The
week-long class focused on the useof the the Cray X-MP/18 in K-12
science education. The NES is a powerful tool that can
dramatically enhance science curriculums with the aid of computer-
generated simulation. NorthWestNet plans to provide NES training
to its K-12 members sometime at the end of this year.
Cooper [Page 21]
Internet Monthly Report April 1992
Eric Hood just returned from North Dakota where he delivered
speeches at the 25th Annual Small College Computing Symposium, at
North Dakota State University, and at a meeting of the North Dakota
Board of Higher Education at the University of North Dakota. His
presentations focused on realizing the advantages of the NREN in
the Northwest, specifically to enable educational programs and to
promote economic development.
NorthWestNet
15400 SE 30th Place, Suite 202 Phone: (206) 562-3000
Bellevue, WA 98007 Fax: (206) 562-4822
Dr. Eric S. Hood, Executive Director
Dan L. Jordt, Director of Technical Services
Schele Gislason, Administrative Assistant
NorthWestNet serves the six state region of Alaska, Idaho, Montana,
North Dakota, Oregon, and Washington.
Dan Jordt <danj@nwnet.net>
NSFNET/ANSNET BACKBONE ENGINEERING
----------------------------------
T3 Network Status
=================
The T3 network remains very reliable and during the month of April
it carried over 50% of total NSFNET packets:
The total inbound packet count for the T1 network was
8,094,303,100, down 23.5% from March. 467,760,160 of these packets
entered from the T3 network. The total inbound packet count for
the T3 network was 8,300,400,177, up 60% from March. 331,145,209
of these packets entered from the T1 network. The combined total
inbound packet count for the T1 and T3 networks (less cross network
traffic) was 15,595,797,908, up 4.6% from March.
This month the cutovers of traffic from the T1 to the T3 backbones
was completed for CICNet, but further cutovers were held until
after the 5 week deployment schedule for RS/960 hardware upgrades
is completed. As of the end of April the first week of RS/960 DS3
card deployment for the Denver and Seattle CNSS nodes, and the
University of Washington, Boulder and Salt Lake City ENSS nodes,
was completed with successful results. New kernel and routing
software was deployed throughout the backbone to prepare for the
remaining RS/960 upgrades.
Cooper [Page 22]
Internet Monthly Report April 1992
T1 Network Status
=================
The T1 network has reached a reasonable level of stability since it
is carrying less than a majority of total traffic. The load on the
RCP nodes is still an issue, since the backbone is still carrying
all routing announcements to and from each regional network. A new
version of rcp_routed is still in testing and will be deployed on
the T1 RCPs during first half of May. This version has the changes
for the second phase of the LSP PDU compression implementation, to
allow more efficient processing of these packets in the RCPs. It
also raises the maximum number of network announcements that can be
accepted at a regional from 2300 to 4500.
T3 Backbone RS/960 Deployment Status - Week 1
=============================================
- RS/960 Hardware Deployment
Early Saturday morning, April 25, the first step of the Phase-III
RS960 DS3 upgrade to the T3 Backbone was completed. The following
T3 backbone nodes are currently running with new T3 hardware and
software in a stable configuration:
Seattle POP: CNSS88, CNSS89, CNSS91
Denver POP: CNSS96, CNSS97, CNSS99
Regionals: ENSS141 (Boulder), ENSS142 (Salt Lake), ENSS143
(U. Washington)
Friday night 5/1 and Saturday morning 5/2, the second step
will occur, with the following nodes being upgraded:
Los Angeles POP (barring rioting, etc.): CNSS16, CNSS17, CNSS19
San Francisco POP: CNSS8, CNSS9, CNSS11
Regionals: ENSS128 (Palo Alto), ENSS144 (NASA Ames/FIX-West),
ENSS135 (San Diego)
- Kernel Build and Routing Software Deployment
Early this morning (April 30), all of the network nodes were
upgraded with Build 2.78.22 and a new version of rcp_routed.
Several nodes (the Step 1 nodes and also the Ann Arbor ENSS) have
been running in this configuration since April 27. This software
build includes drivers for the RS/960 cards, and several bug fixes.
The fixes include reliability improvements to the FDDI software,
notably a soft reset for a hung card; and some additional
improvements to the T960 ethernet and T1 card support to fix a
problem where the card could hang under a heavy load. The
Cooper [Page 23]
Internet Monthly Report April 1992
rcp_routed change includes a fix to a problem that was observed
during RS/960 testing. The problem involved some aberrant behavior
of rcp_routed when a misconfigured regional peer router would
advertise a route via BGP to an ENSS whose next hop was the ENSS
itself. The old rcp_routed could go into a loop sending multiple
redirect packets out on to the subnet. The new rcp_routed will
close the BGP session if it receives an announcement of such a
route. The new rcp_routed software also has support for externally
administered inter-AS metrics, an auto-restart capability, and bug
fixes for BGP overruns with peer routers.
This deployment caused a few problems. One is that this new feature
of rcp_routed pointed out a misconfigured peer router at Rice
University in Houston. This caused the BGP connection to open and
close rapidly which caused further problems on the peer router.
Eventually the peer was reconfigured to remove the bad route, which
fixed the problem. Another problem was on the Argonne ENSS. This
node crashed in such a way that it was not reachable and there was
difficulty contacting the site to reboot the machine. Once the
reboot was done the ENSS came back up running properly. We are
looking into the cause of this crash, as this is the first time
this has happened in all of our testing and deployment. The third
problem was at the CoNCert ENSS, and this node crashed in such a
way that the unix file system was completely lost, and this
requires a complete rebuild of the system. This problem has
happened in two cases previously, and seems to be related to an AIX
problem rather than anything in the new software build. It is an
insidious problem since it completely wipes out any trace of what
may have caused it. We continue to look into this.
In our view, none of these problems are severe enough to call off
the deployment of the RS/960 hardware upgrade on the west coast
Saturday morning. These problems aren't related to the new hardware
or software support for the new cards, but seem to be problems in
other parts of the new software build or routing daemon. The
following section details our experiences of the first week's
deployment. We believe we have an understanding of the problems
that occurred and have increased the number of spare cards in the
kits that the teams will take out to the sites.
Summary of Week 1 (beginning 4/25) RS/960 Deployment
====================================================
Since the deployment, nodes CNSS88 and CNSS96 have been running
with mixed technology (i.e. 3xRS960 T3 interfaces, 1xHawthorne T3
interface). Production traffic on the affected ENSS nodes was
cutover to the T1 backbone at 2:00 AM EST on 4/25. The Denver POP
nodes were returned to full service after approximately 10.5 hours
Cooper [Page 24]
Internet Monthly Report April 1992
and Seattle after about 13 hrs of work.
The new software had been deployed on the affected nodes during the
prior week. The physical upgrade consisted of mechanical changes
to the RS6000 machines including (1) replacement of the RS6000 I/O
planar, (2) replacement of the Hawthorne T3 adapters with RS960
adapters, (3) upgrading the DSU hardware and associated cabling,
(4) a modification of the cooling capabilities of the RS6000, (5)
updating and standardizing on new labels and (6) local software
configuration changes accommodating the use of new hardware. The
nodes were then tested and returned to production service.
Although the resulting configuration is very stable and gratifying
to the team working on the upgrade, the process was not quite as
smooth as had been expected. There were 33 RS960 T3 interface
adapters, T3 DSUs, and 9 I/O planars installed. Out of these, 5
RS960 adapters and 2 I/O planars had to be replaced to achieve
stability. The failing new components were air-shipped back to the
staging lab for a complete failure analysis. and a summary of the
results are described below.
All of the problems involving replaced components have been
identified or explained. The post-manufacturing burn-in and
staging process consists of a stress test involving card-to-card
traffic testing, DSU testing, and power cycling prior to shipping.
Lab burn-in and staging procedures have been adjusted based upon
our experiences with the first deployment step. The installation
procedures will be fine tuned to improve our efficiency and reduce
the installation time required. It is therefore our intention to
continue with the step 2 deployment plan in the San Francisco and
Los Angeles backbone nodes (and adjacent ENSS nodes) on Friday
evening 5/1.
Installation Problems Encountered
=================================
The replacement of the RS6000 I/O planers had to be performed twice
on nodes CNSS88 and CNSS91 after the nodes did not come up properly
the first time. The original set of planers were returned to the
lab for analysis. It was determined that the underside of the
planars were damaged during the physical installation process. The
procedure for installing these planars in the RS6000 model 930 rack
mounted system has been modified to prevent this type of damage
from occuring.
Adapter re-seating and reconfiguration was required on the
asynchronous communications adapter on CNSS89.
Cooper [Page 25]
Internet Monthly Report April 1992
The dual planar change and troubleshooting work adversely affected
the hard disk on CNSS88 and the disk image had to be reloaded from
tape.
An apparent dysfunctional DSU HSSI card connected to CNSS97 was
replaced and was returned for lab failure analysis. The analysis
revealed that a DSU microprocessor was not properly seated. T3
Technologies will re-inspect the DSUs for proper seating of all DSU
components.
The DSU at ENSS142 (Salt Lake City) needed internal work. The
analysis revealed a bent pin on the connector between the HSSI card
and the DSU backplane. T3 Technologies Inc. (DSU manufacturer)
identified a mechanical deficiency in the connector that can cause
certain pins to loosen and bend during insertion of the card. T3
Technologies will add a procedure to inspect these connectors prior
to shipment for any deficiencies.
An RS960 T3 card in CNSS89 did not have the correct electrical
isolation spacers installed, and this caused a temporary short
circuit. The card was returned to the lab and it was determined
that a last-minute change was made to the card to swap an i596
serializer chip and that the spacer was erroneously left off. A
visual inspection procedure for spacers and standoffs will be added
to the manufacturing and staging inspection process.
The RS960 T3 card in CNSS97 came up in a NONAP mode, however the
card continued to respond to DSU queries. The card was replaced.
During the failure analysis, the card passed all stress tests.
This card was swapped prior to a planar change and the NONAP mode
has been attributed to the planar problem.
When reliable connectivity could not be achieved between CNSS97<-
>ENSS141, another RS960 T3 card in CNSS97 was replaced. The lab
failure analysis revealed that the 20Mhz oscillator crystal on the
card was broken due to a mechanical shock. This shock could have
occured during shipping or handling.
CNSS91 rebooted after the upgrade and exhibited an unstable
configuration. Both the I/O planar and the RS960 T3 card were
changed before stable operation was achieved. The RS960 card was
later found to have a cold solder joint between the RAM module and
adapter. The solder joint would allow the card to work when cold,
but would fail intermittently when running hot. A simple adapter
thermal cycling procedure will be investigated to determine if this
problem can be avoided in the future.
Cooper [Page 26]
Internet Monthly Report April 1992
CNSS88 was the last node to come up. The I/O planar and memory
card had to be reseated, and an RS960 T3 card replacement was
necessary. The RS960 card was found to have a solder splash that
was overlapping two adjacent pins. A general corrective action for
this problem involves adding a procedure involving high
magnification visual microchannel interface inspection for shorts.
Conclusions
===========
Although the Step 1 installation was complicated by several
component problems, the entire deployment team (IBM, Merit, ANS,
MCI) has a high comfort level with the results of the failure
analysis, the stability of the resulting installation, and overall
deployment process. We are very encouraged that we have completed
this first step and acheived a very stable configuration within the
time, human resources, spares and support that was provisioned as
part of the deployment plan. The software bring-up and test
scripts worked exactly as planned.
The teamwork between the 50+ individuals involved at Merit, IBM,
MCI and ANS was excellent. The basic installation process is
sound, although some minor changes will be implemented in the
future installation steps. These will include the RS960 adapter
installation, DSU trouble-shooting procedure and the I/O planar
change process. Also the number of spares provisioned in a
deployment kit will be increased as a pre-caution for future
installations.
There has been one software problem identified with the new
technology on the test network since the end of system testing on
4/17. This involves a microcode bug where a portion of the RS960
on-card memory will not report a parity error to the system if that
portion of the memory suffers a failure. All RS960 on-card memory
is tested prior to shipment and a microcode fix to this problem
will be delivered by IBM for testing within the next week. Only a
single RS960 adapter has demonstrated an on-card memory parity
error during all test network testing.
Next Steps
==========
Step 2 of the deployment is currently scheduled to commence at
23:00 local time on 5/1. Step 2 will involve the following
nodes/locations:
Cooper [Page 27]
Internet Monthly Report April 1992
May 1/2
San Francisco, Los Angeles core nodes
T3 ENSS Nodes: Palo Alto E128, San Diego E135,
Other ENSS Nodes: E144, E159, E156, E170 also affected
Second core node visit: Seattle
T3 Backbone RS/960 Deployment Status - Week 2
=============================================
Step 2 of the phase-III network upgrade was successfully completed
last Saturday 5/2. The following T3 backbone nodes are currently
running with new T3 hardware and software in a stable
configuration:
Seattle POP: CNSS88, CNSS89, CNSS91
Denver POP: CNSS96, CNSS97, CNSS99
San Fran. POP: CNSS8, CNSS9, CNSS11
L.A. POP: CNSS16, CNSS17, CNSS19
Regionals: ENSS141 (Boulder), ENSS142 (Salt Lake), ENSS143
(U. Washington)
ENSS128 (Palo Alto), ENSS144 (FIX-W), ENSS135
(San Diego)
CNSS8, CNSS16, CNSS96 are now running with mixed technology (e.g.
3xRS960 T3 interfaces, 1xHawthorne T3 interface). Production
traffic on the affected Bay Area ENSS nodes was cutover to the T1
backbone at 2:00 AM EST on 5/2. Production traffic on ENSS135 was
cutover two hours earlier. The San Francisco and Los Angeles POP
nodes were returned to full service by 10:50 AM EST on 5/2, well
within the planned maintainence window.
The maintainence in the Los Angeles POP was complicated by the
curfew existing at that time. Normally a specially trained 2-3
person deployment team is scheduled to perform these upgrades at
each POP location. Because of the circumstances in Los Angeles, a
special IBM engineer (Carl Kraft) from Gaithersberg, Maryland was
deployed to the Los Angeles POP to perform the upgrade by himself.
Carl was able to upgrade the node single-handedly on schedule.
Several new procedures were developed following the first
deployment step in Seattle and Denver on 4/25. These procedures
helped to reduce the installation window and number of installation
problems experienced on 4/25.
The only problem experienced was the supected failure of a single
RS960 adapter during the installation at ENSS128 (Palo Alto). This
problem was isolated to the adapter within several minutes and the
adapter was swapped resulting in successful operation of the node.
Cooper [Page 28]
Internet Monthly Report April 1992
A subsequent failure analysis of the RS960 adapter has not resulted
in any reproducible problems, and has been attributed to an
improper seating of the adapter in ENSS128 during the initial
installation.
Next Steps
==========
Based upon the successful completion of step 2 of the deployment,
step3 is currently scheduled to commence at 23:00 local time on
5/8. Step 3 will involve the following nodes/locations:
Chicago POP: CNSS24, CNSS25, CNSS27
Cleveland POP: CNSS40, CNSS41, CNSS43
New York City POP: CNSS32, CNSS33, CNSS35
Hartford POP: CNSS48, CNSS49, CNSS51
San Fran. POP: CNSS8 (Second visit to CNSS8->CNSS24 Interface)
Regionals: ENSS130 (Argonne), ENSS131 (Ann Arbor), ENSS132
(Pittsburgh)
ENSS133 (Ithaca), ENSS134 (Boston), ENSS137 D
(Princeton)
Other ENSS's Affected: E152, E162, E154, E158, E167, E168, E171,
E172, E163, E155, E160, E161, E164, E169
The system software (build 2.78.22) required to support RS960
installations has been fully deployed to all T3 network nodes as of
early this week. New rcp_routed software has also been installed
on all T3 nodes, although this is not a pre-requisite for any
phase-III deployment activities. The new rcp_routed software has
enhancements including support for externally administered inter-AS
metrics, an auto-restart capability, and a fix for the invalid
acceptance by the ENSS of a route to itself from a peer.
Following the step 3 deployment, selected T3 internal link metrics
will be adjusted to support load balancing of traffic across the 5
different hybrid technology links that will exist. The selection
of these link metrics has been chosen through a calculation of
traffic distributions on each link based upon an AS<->AS traffic
matrix. This step of the deployment involves 4 POPs, and will
complete the coast to coast RS/960 path for a large proportion of
the backbone traffic.
During the step 3 deployment, the Ann Arbor ENSS will be isolated
from the T3 backbone. Since the Merit/ANS NOC is located in Ann
Arbor, and Merit's backup connectivity to the backbone will be
through the T1 network, we are implementing a backup network
management machine. The "rover" monitoring tool is running on an
Cooper [Page 29]
Internet Monthly Report April 1992
unused RS/6000 CNSS at the Denver POP, and its data collection
capability will be used if there is any problem with Merit's
connection to the T3 backbone.
Also during this deployment the Princeton ENSS will be isolated
from the backbone. This means that both the Ann Arbor T1/T3
interconnect gateway and its backup at Princeton will not be
operational. Therefore on Friday night we will run the Houston
interconnect as primary, and temporarily configure the San Diego
interconnect gateway as secondary with load sharing being handled
as with the Ann Arbor/Houston configuration.
Mark Knopper (mak@merit.edu)
Jordan Becker (becker@ans.net)
NSFNET/INFORMATION SERVICES
---------------------------
Luxembourg is the newest international site among the now 1,806
foreign networks configured for announcement on the NSFNET
infrastructures. A total 5,291 networks are configured at the
close of April 1992, with 3,547 nets announcing to the T3 backbone.
April packet traffic on the NSFNET is discussed in the
NSFNET/ANSNET Backbone Engineering report to the Internet Monthly
Report. NSFNET statistics are available for anonymous ftp from the
directory /nsfnet/statistics on the host nis.nsf.net.
The proposed revision of "Management of Federal Information
Resources," Circular No. A-130 of the Information Policy Branch of
the Office of Management and Budget is available for anonymous ftp
from nis.nsf.net as /omb/omb.a130.rev1 . This document may also be
retrieved by sending an electronic mail message to nis-
info@nis.nsf.net: ignore the subject field, and enter send
omb.a130.rev1 as the first line of the message. Comments may be
sent via electronic mail to omba130@nist.gov and will be included
as part of the official record.
The Subcommittee on Science of the House Committee on Science,
Space and Technology, held a public hearing on the "Management of
the NSF Network" on March 12, 1992 in the Rayburn House Office
Building. Oral and written testimonies given during these
proceedings are available for anonymous ftp from nis.nsf.net in the
directory /internet/legislative.actions/hearing.12mar92 .
Elise Gerich, Merit Internet Engineering, presented the "Report on
the Routing and Addressing (ROAD) Meetings" at the meeting of RIPE
in Amsterdam, The Netherlands. Mark Davis-Craig, Merit Information
Services Specialist, gave an overview of the NSFNET project at
Cooper [Page 30]
Internet Monthly Report April 1992
"Information Technologies on the Frontiers of Learning" sponsored
by the University of Montana, Missoula. Florida State University
(Tallahassee) invited Laura Kelleher, Merit/NSFNET Information
Services, and Dana Sitzler, Merit/MichNet Recruitment, to speak
about the Internet and its resources with faculty, students and
members of FIRN, the Florida Information Resource Network for K-12
educators. Kelleher and Sitzler also met with the America 2000
initiative to discuss networking issues and ongoing programs in
other states.
Registration for "Making Your NSFNET Connection Count," a Merit
Networking Seminar hosted by NevadaNet at the UNLV Campus, remains
open. Donna Cox, director of Numerical Lab Programs at the
National Center for Supercomputer Applications will be the keynote
speaker. Closing remarks will be by Laura Breeden, executive
director of the Federation of American Research Networks (FARNET).
To receive the agenda and registration details, send electronic
mail to seminar@merit.edu or call 1-800-66-MERIT.
Jo Ann Ward (jward@merit.edu)
SAIC
----
In April the VGP module was fully integrated and tested. However,
a two PG/VG model is currently assumed to allow some simplification
of the protocol messages. Also, the implementation assumes
homogenous intra-AD policy and does not implement the policy
specific VGP messages. Originally setup was the next candidate for
integration, however, we chose to move on to the routing
information distribution module at this time instead to better
streamline use of our resources.
Because of funding reallocation for our current contract we have
had to scale down some parts of the implementation effort. IDPR
experimentation must also be scaled down at this point. There have
been some discussions of a cooperative effort with other interested
parties and these will be evaluated during May once the fully
operational GATED implementation is available.
The ISODE_SMUX interface for SNMP available with GATED is
sufficient for implementation of the IDPR MIB. However, because of
the reduction of funding, there are no current plans to implement
the MIB.
Ken Carlberg has completed an implementation of multicast
extensions to CLNP with Bob Harris from Sparta. A demo is
scheduled for May 13th.
Cooper [Page 31]
Internet Monthly Report April 1992
Planned Activities:
This is the final stretch for the GATED implementation of IDPR.
The remaining modules will be integrated and tested during the
first three weeks of May. Lab experimentation with policies will
begin in June and extend until the beginning of July. It is
expected that some wider experimentation and demonstration will
take place in July.
Woody Woodburn will be traveling to SRI in Menlo Park, CA to help
them use this new IDPR implementation in a policy based
application.
Robert "Woody" Woodburn <woody@sparta.com>
SDSC (SAN DIEGO SUPERCOMPUTER CENTER)
-------------------------------------
SDSC Network Activities
Since our last report several things have happen in San Diego.
CERFnet has moved out of our building for larger digs down the
street at General Atomics.
SDSC & CERFnet have made several local routing changes to support
an expanded FDDI and to more fully use the T-3 NSFnet.
The single AS 195 both had used was split such that CERFnet now has
their own (AS 1740). This exercise was followed by several days of
routing changes. We now have a configuration which seems stable
and has the major routing functions being servered by boxes which
are not also very busy packet switches. We are looking forward to
the 2 May upgrade of our ENSS.
SDSC was local host to the 23rd Internet Engineering Task Force
meeting at the Hyatt Islandia 16-20 Mar. Donations where made by
PacBell of a T-1 circuit for the meeting and by DEC, SUN, HP, NCD,
Verilink, GA, and UCSD of networking equipment, workstations, X-
Terms, etc. CERFnet provided the Internet IETF was the first to
carry portions of the proceedings via packet audio. A lot of hard
work was put in by Susie Arnold, Don Doering, Jay Dombrowski, Rich
Gallup, Tom Hutton, Kevin Fall, John Moreland, Gerard Newman, Rick
Pattela, and Mike Robertson to get everything installed and
operational on time. The local hosts were Hans-Werner Braun and
Paul Love.
Cooper [Page 32]
Internet Monthly Report April 1992
SDSC participated in the joint Merit/FARnet demonstration area at
National Net92.
We are in the process of upgrading our UltraNet to version 4.0.
Miscellaneous
Paul Love attended the NSF/FARnet "Tempering the Network" workshop
held in Orlando, FL., and a FARnet board retreat held at University
of Maryland.
SDSC Applied Network Research Group
SDSC is pleased to welcome Bilal Chinoy to the ANR staff of SDSC as
of Feb. For several years, Chinoy has been involved in advanced
networking issues, including analysis, planning, engineering and
operations at Merit. He was instrumental in the implementation of
the NSFNET backbone project. Chinoy will be of great benefit to
the SDSC Applied Network Research group.
Chinoy will be devoting his attention to a NSF sponsored network
analysis and modeling project. He will also be working on the CASA
gigabit testbed project, for which he is a SDSC co-PI.
CASA gigabit project
Chinoy is continuing the efforts in progress on the HIPPI network
simulator. These are in cooperation with researchers at LANL. We
also expect to soon begin network performance related work on our
HIPPI crossbar switch connected to the SDSC CRAY Y-MP.
Network analysis project
Research efforts are continuing in the development of systematic
methodologies for network analysis and performance testing. Our
investigations involve very large data sets, often in the size
range of 500 megabytes to 1 gigabyte. For the most part the
analysis programs utilize an RS6000 workstation contributed by IBM
for projects related to network analysis.
We have completed a collaborative investigation with a group of
network analysts in Japan, and are currently in the middle of
another collaborative effort with researchers at FIX-West at NASA-
Ames. Both studies are one shot examinations of relatively short
intervals of network traffic. The measurement methodology was
equivalent: we collected packet header traces at the remote site,
and subsequently performed local post-processing on the collected
data.
Cooper [Page 33]
Internet Monthly Report April 1992
We are also currently investigating NSFNET statistics collected
operationally by Merit, and trying to extract meaningful insights
from the data. Analysis efforts are currently focused on the
following areas:
- latencies and their relationship to resource consumption
- performance degradation under resource starvation
- levels of granularity of both analysis and sampling
- application distribution
- geographic traffic distribution.
During the March IETF meeting held in san Diego, the Applied
Network Research Group gave a presentation at a plenary session.
The group also participated in an IETF BOF dedicated to wide area
network traffic characterization. One of our long-term goals is to
arrive at a set of requirements for evaluating and instrumenting
high speed, wide area networks. We hope these and other activities
at SDSC encourage collaborative efforts within the community in the
area of high speed network traffic characterization.
by Paul Love <loveep@sdsc.edu >
SRI
----
SRI's Network Information System Center (NISC) updated the RFC
Index in response to each RFC issued in March and April. There
were eight RFCs issued in March 1992 and ten RFCs issued in April
1992.
The RFC Index contains citations of all RFCs issued to date in
reverse numeric order. It's also a quick reference to determine if
any RFC has been obsoleted and gives a pointer to the replacement
RFC.
The RFC Index also supplies the equivalent FYI number, if the RFC
was also issued as an FYI document.
Paper copies of all RFCs are available from SRI, either
individually or on a subscription basis (for more information
contact nisc@nisc.sri.com or call 1-415-859-6387). Online copies
are available via FTP from ftp.nisc.sri.com as rfc/rfc####.txt or
rfc/rfc####.ps (#### is the RFC number without leading zeroes).
Cooper [Page 34]
Internet Monthly Report April 1992
Additionally, RFCs may be requested through electronic mail from
SRI's automated mail server by sending a message to mail-
server@nisc.sri.com. In the body of the message, indicate the RFC
to be sent, e.g. "send rfcNNNN" where NNNN is the number of the
RFC. For PostScript RFCs, specify the extension, e.g. "send
rfcNNNN.ps". Multiple requests can be sent in a single message by
specifying each request on a separate line. The RFC Index can be
requested by typing "send rfc-index".
April Marine, co-chair of the Network Information Services
Infrastructure User Services Working Group of the IETF, attended
the March 1992 meeting of the IETF held in San Diego, California.
One of the major topics discussed was locating and indexing
information on the Internet via tools such as Archie, WAIS, and
Prospero.
Two new documents, Internet:Getting Started and Internet:Mailing
Lists, are now available from the NISC. Contact the NISC directly
for more information.
Sue Kirkpatrick <sue@NISC.SRI.COM>
UCL
----
Two reports describing recent work are available:
1. Multimedia Conferencing: from prototype to national pilot
At University College we have developed a multimedia conferencing
system as part of the CAR project funded by the European Commission
RACE Program. This conferencing system is aimed at assisting
distributed collaborative design in the automotive industry. It
runs over basic rate ISDN lines, with video and audio provided by
integrated video switching and ISDN video codecs.
This paper describes some of our experiences with wide area
multimedia conferencing, both from the workstation based approach
and from the point of view of interconnecting studios and large
conferences using digital networks. We are currently involved in
the planning of the SuperJanet broadband network which will enable
routine use of multimedia services between research and academic
institutions in the United Kingdom. We describe some of the
services that it will be possible to provide, both for workstation
and studio based multimedia services, and the necessary local
infrastructure that will be required.
Cooper [Page 35]
Internet Monthly Report April 1992
(To be presented at INET 92 in Kobe)
postscript in: car-inet92.ps
2. Lessons and Challenges of Distributed Computing
This document is edited from a number of contributions to a lively
debate on the lessons and challenges of distributed computing. The
debate was initiated by Prof A Tanenbaum on the bulletin board
comp.os.research.
The text is almost entirely culled from the bulletin board
contributions, except for occasional introductory material
indicated by the use of bold font.
postscript, or compressed (binary) postscript in:
dos-sum.ps or dos-sum.ps.Z
ftp from cs.ucl.ac.uk (128.16.5.31),
both in directory car/
John Crowcroft (j.crowcroft@CS.UCL.AC.UK)
UNIVERSITY OF DELAWARE
----------------------
1. The NTP Version 3 specification document has appeared as
rfc1305. It is in PostScript form in three files
rfc1305{a|b|c}.ps which will probably dim the lasers of the
less ambitious printers. Those lacking that ambition may see
the ASCII mangling in rfc1305.txt, but not the figures, tables
and equations necessary to fully understand the stuff.
2. We have given up, at least temporarily, finding the varmit
causing the interference to our WWVB timecode receiver and
sent the spare receiver to MIT for use there. Meanwhile, our
NTP-in-a-box gadget expired and was returned for repair.
However, we now have a working GPS receiver, but are in the
midst of an antenna resiting project. Time lurches on.
Dave Mills (Mills@UDEL.EDU)
Cooper [Page 36]
Internet Monthly Report April 1992
WISCNET
-------
Line reset problems in the Milwaukee area were traced to software
interactions between saturated router interfaces on the UW-
Milwaukee router. Some relief was effected by reallocation of
bandwidth on the underlying T1 network providing more bandwidth on
the Milwaukee - Madison link. The problem was resolved by
installation of new software on the UW-Milwaukee router. The
software is being installed on all WiscNet routers.
WiscNet recently sponsored the first of what it expects to be
annual conferences on topics of interest to members. WiscNet
Conference 1992, organized by the network's User Services Committee
and held at the University of Wisconsin - Stevens Point April 28
and 29, was developed around the theme "Highway to Resources:
Providing Services Easily and Effectively."
Timed to dovetail with the annual conference of the Wisconsin
Association of Academic Librarians, the WiscNet event drew more
than 190 attendees together for 11 sessions covering such topics as
desktop TCP/IP, ethics and policy in computing, electronic
libraries in action, access to Internet resources, multicultural
opportunities in the classroom, and so forth. Speaking at a
general session, keynoter Paul Evan Peters, Director of the
Coalition for Networked Information, highlighted rapidly unfolding
developments in networking that are creating an entirely new
environment for the management and use of information, amounting to
a co-evolution of technological, intellectual, and organizational
models.
Conference attendees comprised both computing and library
professionals. Responses to the conference sessions were
enthusiastically positive. Plans are already underway for a second
annual conference, to be held next year.
Jess Anderson (anderson@macc.wisc.edu)
Michael Dorl (dorl@vms.macc.wisc.edu)
Cooper [Page 37]
Internet Monthly Report April 1992
DIRECTORY SERVICES
------------------
This section of the Internet Monthly is devoted to efforts working to
develop directory services that are for, or effect, the Internet. We
would like to encourage any organization with news about directory
service activities to use this forum for publishing brief monthly news
items. The current reporters list includes:
o IETF OSIDS Working Group [no]
o IETF DISI Working Group [no]
o Field Operational X.500 Project [no]
- ISI [no]
- Merit [no]
- PSI [no]
- SRI [no]
o National Institute of Standards and Technology [no]
o North American Directory Forum [no]
o OSI Implementor's Workshop [no]
o PARADISE Project [no]
o PSI DARPA/NNT X.500 Project [included]
o PSI WHITE PAGES PILOT [included]
o Registration Authority Committee (ANSI USA RAC) [included]
o U.S. Department of State, Study Group D,
MHS Management Domain subcommittee (SG-D MHS-MD) [included]
o USENET-Addresses Database [included]
Additionally, this month's DSAR features a special item: a report on
the X.500-accessible "usenet-addresses" database being developed at
UIUC.
Tom Tignor (tpt2@isi.edu)
DS Report Coordinator
PSI DARPA/NNT X.500 Project
---------------------------
Much of the work performed this month was related to following up
on the Internet Engineering Task Force meeting last month. In
particular:
- A preliminary draft of a MIB that current instruments
X.400 MTAs and X.500 DSAs was reviewed. Comments have
been submitted to the author.
- Based on comments received on the LDBP at the IETF meeting,
the scope of the protocol was expanded to include
simple Directory management, and a new specification,
Cooper [Page 38]
Internet Monthly Report April 1992
renamed the Lightweight Directory Access Protocol (LDAP)
has been resubmitted.
- A new draft of RFC1279 containing changes suggested at the
IETF meeting was reviewed. A minor modification was also
made to the 'fred' software due to a bug that was uncovered
during the IETF discussion on the DNS in X.500.
Beta testing was performed on an interim release of the ISODE QUIPU
software. Further testing will be performed over the next few
months.
Wengyik Yeong (yeongw@psi.com)
PSI WHITE PAGES PILOT PROJECT
-----------------------------
The following organizations joined the pilot this month:
Martin Marietta
Indiana University
Harvey Mudd College
University of Akron
Wengyik Yeong (yeongw@psi.com)
REGISTRATION AUTHORITY COMMITTEE (ANSI USA RAC)
-----------------------------------------------
The USA-RAC (ANSI USA Registration Authority Committee) is working
on plans to restructure the way it has been using a single arc
under ISO { iso (1) member-body (2) us (840) } for registration of
State Names, ANSI Standards, and Private Organizational Names with
US National Standing.
The primary motivation is provided by the recent changes in ISO
9834-1 (also now known as CCITT X.660) which requires that
Organizational Names with National Standing be henceforth
registered under a new joint arc ( joint-iso-ccitt (2) country (16)
us (840) }.
It has recently become apparent that the original scheme for
registering several different types of names, which are used for
different attribute values (as in X.500 stateOrProvince and
Organization) will only cause trouble in the future.
The plan that is developing, but which is not yet adopted by
anyone, is projected below. This is an informal report and is not
Cooper [Page 39]
Internet Monthly Report April 1992
blessed by USA-RAC in any way.
First let me describe the original scheme:
1. The FIPS-5 registration of all US States and State Equivalents
which has been done by a US Government Commission was copied
(both alpha and numeric assignments) into the lowest 100
numeric name slots. This is a poor idea in any case, since
it is always bad to copy in this way, and hope to stay in sync
over time.
2. ANSI Standards were allocated the numeric name spaces between
10,001 and 20,000.
3. Organizations were allocated all the numeric name spaces above
113,527 to 16,000,000.
Any name registered in these ranges must have a numeric value
assigned, and may also have a single Alphanumumeric value
associated with the Numeric value in the register.
Second, here is the new plan, with transitions as indicated:
It is clear that policy control over { 2 16 840 } must be shared
between ANSI and the US Dept of State.
4. The new arc will only register subauthorities, such as FIPS-5,
and will not copy anything from FIP-5. These are (for the
moment):
{ 2 16 840 fips-5(1) },
{ 2 16 840 organizations(2) },
and { 2 16 840 mhsmd(3) }
5. The FIPS-5 commission will be delegated to maintain the
( 2 16 840 1 } register. This supports the NADF plan to use
FIPS-5 as the source of values for the stateOrProvince RDN
AVAs under c=US.
The current "registration" of states in { 1 2 840 } will
simply be abandoned, since no one has registered anything under
them as yet.
6. ANSI is expected to operate the ( 2 16 840 2 } register of
organizations with national standing. Existing registrations
of organizations (approximately 54 at this date) in { 1 2 840 }
will be copied over to the new { 2 16 840 2 } arc with the same
values at no charge to the registrant.
Cooper [Page 40]
Internet Monthly Report April 1992
This causes some complications, since this will give current
organizational registrants a second OID prefix to administer.
Registrants get their choice of which arc they wish to use.
It will be recommended that they not add new registrations to
the { 1 2 840 n } arcs they now have, and use the new
{ 2 16 840 n } arc instead, for new object definition
registrations. X.500 use of their registered Alphanumeric
Names will not be affected in any way.
7. A new arc { 2 16 840 3 } will be established for MHSMD name
registrations.
8. ANSI Standards will be left where they are under { 1 2 840 }.
9. The numeric values under { 2 16 840 organizations(2) } are
planned to be used for NSAPs with AFI of 38 or 39, and IDI
of 840; for OID registration of information objects in
organizational (sub)authority registers, and for AETitle
registrations in organizational (sub)authority registers.
AETitles, per new draft ISO standards will require a pair of
Alphanumeric and Numeric values such that either can be used
as a DN in X.500 to dereference the AETitle DN in an X.500 DIT.
I expect that one will be an alias for the other in most
instantiations, but it is conceivable that they might be
instantiated with replications of the same entry.
Respectfully submitted without USA-RAC blessing by...Stef
Einar Stefferud (stef@ics.uci.edu)
SG-D MHS-MD
-----------
After considerable turmoil with a change of Chair and a great deal
of deep thought, MHSMD is moving toward consensus on a number of
key issues. This report does not report official positions, but
contains my interpretation of where things seem to be headed.
Registration of MHSMD Names:
++++++++++++++++++++++++++++
I has been concluded (pretty much) that there is just no way to
overlay the ANSI Organizational Name Registry with the MHSMD Name
Registry, so they are about to become divorced and exist as
separate uncoordinated name space registries. This means that a
currently registered ANSI Organizational Name will not be usable as
an ADMD or PRMD name in an X.400 ORAddress in /C=US/ without also
Cooper [Page 41]
Internet Monthly Report April 1992
registering it in the new MHSMD Name Registry. (Sorry about that!)
There are many many reasons for this, but the primary one is that
the two name spaces simply have very different requirements which
make it impossible to devise a single set of policies for a joint
use register.
For one, the character sets and string lengths are different.
X.400 limits MHSMD names to 16 characters of printable string, and
this creates a serious real estate problem and increases the
likelyhood of collisions. I will not try to delineate the entire
list of such issues. I hope it will suffice to say that there will
be two separate and uncoordinated registers. This means that no
attention will be paid to who has registered what names in the
other register, although we expect the owners of registered names
to pay attention for possible encroachment. It should help to note
that by and large, people just do not pick names that will be
confused with other names when they are selecting distinctive
names.
Also, it is agreed in principle that MHSMD Registry Names will not
be accompanied by any Numerical Name Value (a Numberform Value),
since there is no need for such things in X.400. This eliminates a
serious conflict (Standards Defect) wherein Numberform Values and
Printable strings that consist of only digits are not
distinguishable in the X.400 protocol. With no Numberform Values
assigned in /C=US/, this problem goes away for /C=US/ Oraddresses.
Next, it is proposed that the MHSMD Name Register should be lodged
as an arc under the new {joint-iso-ccitt(2) country(16) us (840) }
arc which we understand must be jointly controlled by ANSI (the ISO
MemberBody for c=US), and the US Dept of State (the CCITT
MemberBody for /C=US/). This new arc is administered under the
rules stated in CCITT X.660 which is a duplicate of the text in the
revised ISO 9834-1.
MHSMD is currently working very closely with USA-RAC to achieve
total sync. Much of this is done via dual memberships, and the
rest is done with joint meetings.
There is more to the MHSMD Name Space Story (namely
(sub)authorities), but we need some discussion of ADMD/PRMD
Behavior Rules first.
Cooper [Page 42]
Internet Monthly Report April 1992
Behavioral Rules for ADMD and PRMD operators:
++++++++++++++++++++++++++++++++++++++++++++
This work is less well formed at present, but I can say some things
for certain.
The ITU (International Telecommunications Union) Treaty requires
that every country (including /C=US/) must arrange for any foreign
X.400 ADMD operator to be able to connect to and thus accomplish
delivery of messages to any user of any ADMD Service Provider's
X.400 services, and vice versa. (This is the best I am able to
state this in brief.)
So, it is imperative for the /C=US/ ADMD Operators to voluntarily
organize themselves to accomplish this, hopefully without
Congressional, FCC, or other US Government action to make it
happen.
So, here is what seems to be jelling:
The proposed plan is patterned after the British Standards
Institute (BSI) requirements for all /C=GB/ ADMD operators to join
in forming a single GB backbone, and giving every PRMD customer the
unilateral choice of using the ADMD name of the Backbone (i.e.,
<single-space>), or using the name of their ADMD service provider
(i.e., BT GOLD). The really big difference is that MHSMD envisions
backbone participation to be voluntary on the part of every ADMD
Service Provider, so there will be some ADMD service providers
which are not participants. All ADMD service providers will be
required however to be able to connect with all others in /C=US/
and to handle mail to and from any foreign ADMD service providers.
Under the ITU treaty, ADMD service providers cannot remain
unconnected for purposes of supporting X.400 mail exchanges with
foreign ADMD service providers. The ITU says nothing about
domestic interconnection requirements.
A second very important difference between /C=US/ and /C=GB/ is
that it is agreed that the name used to identify the /C=US/ X.400
backbone will not be <single-blank>. MHSMD recognizes and agrees
that <single-blank> is a terrible name, and that it carries with it
some risk that some foreign ADMD operators my unilaterally refuse
to honor or route on such a name (though the standards do not offer
them this option). We just don't want to mess with the issues, and
they can all be circumvented by choosing a real name with visible
characters, and which is indistinguishable from any other
character-full name.
Cooper [Page 43]
Internet Monthly Report April 1992
(I cannot help but note with some humor that X.400 disallows any
ADMD or PRMD name to contain any leading or trailing blanks, and
then at the same time, allows a <single-blanK> to be an ADMD Name
which in a single character contains both violations.)
The temporary /C=US/ backbone ADMD name used for now is USMTS.
This is understood to be a placeholder while we search for an
acceptable name to use. Proposals are welcome;-).
Beyond this, the rules are not stable, but work is going on to
examine the many possible scenarios of interconnection to be sure
that there are no technical problems with compliance. It should be
assumed that the involved ADMD service providers are all paying
attention to the settlements issues, et al.
A key concept is that the only information that must be shared
among the ADMD participants in the /C=US/ backbone is reachability
information regarding connected PRMDs. This is much like an MX
record that only tells what ADMD can deliver to a given PRMD. We
have not identified any other information that needs to be shared.
Among the principles of agreement here is the idea that any PRMD
must be allowed to decide what PRMD name it will use (within the
limits of Intellectual Property Law which provides unicity), and
which and how many ADMDs the PRMD will connect to. This leads to
some requirements for "portable names" that can be used with any
ADMD (e.g., National Uniqueness and National Standing so they can
be used under /C=US/ADMD=USMTS/ in ORAddresses). The MHSMD Name
Register is being defined to provide for registration of these
names.
MHSMD (Sub)Authorities and the Constructive Syntax:
++++++++++++++++++++++++++++++++++++++++++++++++++
You may have seen it around before, but here is a thumbnail sketch.
By restricting the use of the +sign in certain ways, such as in an
MHSMD registered name, we can use the +sign as a constructor in a
name constructed by a subauthority, in much the same way that .dot
delimits constructed DNS subdomain names. So, if an ADMD (or
anyone else) permanently registers an MHSMD name in the MHSMD
register, then that name may be used as the prefix for
construction, by appending to it a +sign, followed by a
"subauthority-determined-part". This should not seem odd to
internet veterans.
It is required that the (sub)authority registrant pay for a
permanent (perpetual) name registration that will not expire
Cooper [Page 44]
Internet Monthly Report April 1992
because it must remain responsible for acting as a (sub)authority
registrar for all the names that it constructs for PRMDs that
register under it.
Thus, you might someday see things like "PRMD=ATT+ACME SIGNS", etc.
Or, "PRMD=MCI+1234". Or someone may register XYZ and go into
business registering names like "PRMD=XYZ+MUMBLE". All these
names, by the construction rules, are nationally unique and have
national standing.
Some people (many in DOE, the AIA, and EMA) intensely dislike this
constructive syntax idea, because (they say) "such names are ugly
and we don't want to see them in ORAddresses". There are also
claims that allowing anyone to use such names will hurt the
prognosis for X.400 deployment.
My position on this is that if this kind of thing can seriously
impact X.400 deployment, there must be something very wrong
somewhere else!
Actually what is now propelling the constructive syntax band wagon
is that it serves to solve a very knotty problem with
grandfathering all the names already in use in /C=US/ by our
currently operating ADMDs.
The tentative MHSMD agreements call for every ADMD operator to in
fact be a (sub)authority (which must have a permanent MHSMD
registration for its ADMD name). Then, each ADMD can register PRMD
names in one of two ways:
1. In constructive syntax mode, or
2. In simple mode as a PRMD name that is qualified by the superior
ADMD name. In this case, the registered PRMD name is only
guaranteed to be unique when used in association with the
registering ADMD.
Mode 2 takes care of grandfathering whatever names are already in
use.
Mode 1 allows any ADMD to continue acting as an X.400 PRMD Name
(sub)authority, with a capability of generating and registering
PRMD names that are Nationally Unique and have National Standing,
which will allow the registrant to use the name with any other
ADMD, including USMTS. You should note that PRMD=MCI+1234 will be
able to sign up with ADMD=USMTS using PRMD=MCI+1234.
Cooper [Page 45]
Internet Monthly Report April 1992
Conclusion:
+++++++++++
I hope this all makes sense to everyone. It is being done to break
a serious impasse that has stymied the work of MHSMD for the last 2
years.
Respectfully submitted without MHSMD review by...Stef
Einar Stefferud (stef@ics.uci.edu)
USENET-ADDRESSES DATABASE
-------------------------
The "usenet-addresses" database is about 200,000 e-mail addresses
lifted from usenet news postings and indexed with WAIS (a Z39.50
implementation via Thinking Machines). It's running at
wais.cic.net and at pit-manager.mit.edu. The data is also
accessable via a wais to gopher gateway running at the U of
Minnesota.
The non-X.500 "phone book" protocol which seems to have gotten the
widest implementation is the CSO name server, developed at UIUC.
CSO phone books can be located with the help of gopher and searched
through that interface. There is also a telnet-based X.500 search
available via the Minnesota gopher.
A challenge as I see it is to provide support for X.500 queries,
either directly or via gateways, in the new crop of multi-protocol
Internet browsing and searching clients (Gopher, World Wide Web,
WAIS). This is complicated somewhat by the relative ease of
software development in the TCP/IP and OSI environments. The
appearance of "simple" X.500 interfaces, or translating gateways
that spoke something dumb like finger on one side and retrieved
directory entries out the other would ease in the integration
process.
Meanwhile, real users blunder on using whatever means are at their
disposal -- business cards, yellow sticky notes, pocket organizers,
etc. -- to locate and remember the mail addresses of colleagues.
With ca. 7 million people on the net and more appearing all the
time I guess it's not surprising that the process is harder than
you'd hope it might be.
Edward Vielmetti, Vice President for research, MSEN Inc.
(emv@msen.com) MSEN Inc., 628 Brooks, Ann Arbor MI 48103
+1 313 741 1120
Cooper [Page 46]
Internet Monthly Report April 1992
CALENDAR
--------
Readers are requested to send in dates of events that are
appropriate for this calendar section.
1992 CALENDAR
May 4-6 ANSI X3T5
May 4-8 DECUS '92, Atlanta, GA
May 4-8 IEEE INFOCOM'92, See IEEE Pub., Florence, Italy
May 11 T1E1, Physical Layer Interfaces (ISDN, T1,
Broadband, etc.)
Williamsburg, VA, Bell Atlantic
May 12-14 Joint Network Conference 3, Innsbruck, Austria
(this is the RARE Networkshop - renamed)
May 13-15 Third IFIP International Workshop on Protocols
for High Speed Networks, Stockholm, Sweden
Contact: Per Gunningberg, per@sics.se
Bjorn Pehrson, bjorn@sics.se,
Stephen Pink, steve@sics.se
May 18-25 INTEROP92, Washington, D.C.
Dan Lynch (dlynch@interop.com)
May 19-29 ISO/IEC JTC 1/SC 21, Ottawa, Ontario, Canada
May 27-29 IFIP WG 6.5 Int'l Conference on Upper Layer
Protocols, Architectures and Applications
Vancouver, Canada
plattner<plattner@komsys.tik.ethz.ch>
Gerald Neufeld <neufeld@cs.ubc.ca>
Jun 8 T1M1, Management and Maintenance (ISDN,
Broadband, Frame Relay, etc.)
Minneapolis, MN, ADC TElecom
Jun 8-12 OIW, NIST, Gaithersburg, MD
Jun 10-11 RARE WG1, tentative-Location unknown
Jun 11-12 RARE COSINE MHS MGR, tentative-Location unknown
Jun 14-17 ICC-SUPERCOMM'92, Chicago, IL. See IEEE Publ..
Jun 15-19 INET92, Kobe, Japan
Jun Murai (jun@wide.ad.jp), KEIO University
Elizabeth Barnhart (barnhart@educom.edu)
"North America Contact"
Jun 23-25 ANSI X3S3.3, Raleigh, NC
Jun 22-25 PSTV-XII, Orlando, Florida
Umit Uyar, ATT Bell Labs, <umit@honet5.att.com>
Jerry Linn, NIST <linnrj@ECF.NCSL.NIST.GOV>
Jun 29-Jul 1 Fourth Workshop on Computer-Aided Verification
(CAV 92); see Sigact News, Vol, 22 No. 4
Montreal Canada
G. Bockmann: bochmann@iro.umontreal.ca
Cooper [Page 47]
Internet Monthly Report April 1992
Jul 6-10 IEEE802 Plenary, Bloomington, MN
Jul 13-17 ANSI X3T5
Jul 13-17 IETF, Cambridge, Mass.
<ietf-rsvp@nri.reston.va.us>
Jul 13-24 ISO/IEC JTC1/SC6, San Diego, CA
Aug 2 T1S1, Call Control and Signaling (ISDN,
Frame Relay, Broadband ATM)
Aug 16 T1S1, Call Control and Signaling (ISDN,
Frame Relay, Broadband ATM)
Aug 17-20 SIGCOMM, Baltimore, MD
Deepinder Sidhu, UMBC
Aug 18-21 ACM SIGCOMM '92, Baltimore, Maryland
<sigcomm92@nri.reston.va.us>
Aug 24-27 CONCUR '92 -- Third Int'l Conference on
Concurrency Theory (Paper deadline March 1, 1992)
Rance Cleaveland (rance@csc.ncsu.edu)
Scott Smolka (sas@sunysb.edu)
Stony Brook
Sep 7-11 12th IFIP World Computer Congress
Madrid, Spain; Contact: IFIP92@dit.upm.es
Sep 8-10 ANSI X3S3.3, Minneapolis, MN
Sep 14-18 ANSI X3T5
Sep 21-25 OIW, NIST, Gaithersburg, MD
Sep 28-30 5th IFIP International Workshop on Protocol
Test Systems (IWPTS), Montreal, Canada
iwpts@iro.umontreal.ca
Oct 12-16 FORTE'92, Lannion, France
Roland Groz (groz@lannion.cnet.fr)
Michel Diaz (diaz@droopy.laas.fr)
Oct 26-30 INTEROP92, San Francisco
Dan Lynch (dlynch@interop.com)
Oct 28-29 NETWORKS '92, Trivandrum, India
S.V. Raghavan (raghavan@shiva.ernet.in)
Nov 8-11 Twentieth ACM/SIGUCCS Conference
Stouffer Tower City Plaza Hotel, Cleveland, Ohio
Al Herbert (HERBERT@UAKRON.EDU)
Nov 9-13 ANSI X3T5
Nov 10-12 ANSI X3S3.3, Mountain View, CA
Nov 16-20 IETF, Washington, D.C.
<ietf-rsvp@nri.reston.va.us>
Dec 6-9 GLOBECOM '92, Orlando, Florida (See IEEE Publ.)
Dec 7-11 DECUS '92, Las Vegas, NV
Dec 14-18 OIW, NIST, Gaithersburg, MD
Cooper [Page 48]
Internet Monthly Report April 1992
1993 CALENDAR
Mar 8-12 INTEROP93, Wasington, D.C.
Dan Lynch (dlynch@interop.com)
Mar 8-12 OIW, NIST, Gaithersburg, MD
Mar 28-Apr2 IETF, Columbus, Ohio
<ietf-rsvp@nri.reston.va.us>
Apr 18-23 IFIP WG 6.6 Third International Symposium
on Integrated Network Management, Sheraton
Palace Hotel, San Francisco, CA (kzm@hls.com)
May 23-26 ICC'92, Geneva, Switzerland
May-Jun PSTV-XIII, University of Liege.
Contact: Andre Danthine,
May 23-26 ICC '93, Geneva, See IEEE Publications.
Jun 7-11 OIW, NIST, Gaithersburg, MD
Aug 18-21 INET93, San Francisco Bay Area
Aug 23-27 INTEROP93, San Francisco
Dan Lynch (dlynch@interop.com)
Aug SIGCOMM, San Francisco
Sep ?? 6th SDL Forum, Darmstadt
Ove Faergemand (ove@tfl.dk)
Sep 13-17 OIW, NIST, Gaithersburg, MD
Sep 20-31 ISO/IEC JTC1/SC6, Seoul, Korea.
Oct INTEROP93, Paris, France
Oct 12-14 Conference on Network Information Processing,
Sofia, Bulgaria; Contact: IFIP-TC6
Nov 9-13 IEEE802 Plenary, LaJolla, CA
Dec 6-10 OIW, NIST, Gaithersburg, MD
1994 CALENDAR
Apr 18-22 INTEROP94, Washington, D.C.
Dan Lynch (dlynch@interop.com)
Aug 29-Sep 2 IFIP World Congress
Hamburg, Germany; Contact: IFIP
Sep 12-16 INTEROP94, San Francisco
Dan Lynch (dlynch@interop.com)
1995 CALENDAR
Sep 18-22 INTEROP95, San Francisco, CA
Dan Lynch (dlynch@interop.com)
-------------------------------
Note:
T1E1: Physical Layer Interfaces (ISDN, T1, Broadband, etc.,)
T1M1: Management and Maintenance (ISDN, Broadband, Frame
Relay, etc.)
Cooper [Page 49]
Internet Monthly Report April 1992
Cooper [Page 50]