As per Relevance of the word february, we have this rfc below:
Network Working Group R.
Request for Comments: 1070 U of Wiscsonsin -
N.
U of Wiscsonsin -
M.
The Wollongong
February 1989
Use of the Internet as a Subnetwork
Experimentation with the OSI Network
Status of this
This RFC proposes a scenario for experimentation with
International Organization for Standardization (ISO) Open
Interconnection (OSI) network layer protocols over the Internet
requests discussion and suggestions for improvements to
scenario. This RFC also proposes the creation of an experimental
internet. To participate in the experimental OSI internet, a
must abide by the agreements set forth in this RFC. Distribution
this memo is unlimited
The methods proposed in this RFC are suitable ONLY for
use on a limited scale. These methods are not suitable for use in
operational environment
Since the International Organization for Standardization (ISO)
Systems Interconnection (OSI) network layer protocols are in
infancy, both interest in their development and concern for
potential impact on internetworking are widespread. This
has grown substantially with the introduction of the US
OSI Profile (GOSIP), which mandates, for the US Government, the
of OSI products in the near future. The OSI network layer
have not yet received significant experimentation and testing.
status of the protocols in the OSI network layer varies from
International Standard to "contribution" (not yet a Draft Proposal).
We believe that thorough testing of the protocols and
of the protocols should take place concurrently with the
of the protocols to ISO standards. For this reason, the creation
an environment for experimentation with these protocols is timely
Thorough testing of network and transport layer protocols
Hagens, Hall, & Rose [Page 1]
RFC 1070 Experimental OSI Net February 1989
internetworking requires a large, varied, and complex environment
While an implementor of the OSI protocols may of course test
implementation locally, few implementors have the resources to
a sufficiently large dynamic topology in which to test the
and implementations well
One way to create such an environment is to implement the OSI
layer protocols in the existing routers in an existing internetwork
This solution is likely to be disruptive due to the immature state
the OSI network layer protocols and implementations, coupled with
fact that a large set of routers would have to implement the
network layer in order to do realistic testing
This memo suggests a scenario that will make it easy for
to test with other implementors, exploiting the existing
of the Internet without disturbing existing gateways
The method suggested is to treat the Internet as a subnetwork
hereinafter called the "IP subnet." We do this by encapsulating
connectionless network layer protocol (ISO 8473) packets in
datagrams, where IP refers to the Internet network layer protocol
RFC 791. This encapsulation occurs only with packets travelling
the IP subnet to sites not reachable over a local area network.
intent is for implementations to use OSI network layer
directly over links locally, and to use the IP subnet as a link
when necessary to reach a site that is separated from the source
an IP gateway. While it is true that almost any system at
participating site may be reachable with IP, it is expected
experimenters will configure their systems so that a subset of
systems will consider themselves to be directly connected to the
subnet for the purpose of testing the OSI network layer protocols
their implementations. The proposed scheme permits systems to
their topological relationship to the IP subnet at any time, also
change their behavior as an end system (ES), intermediate
(IS), or both at any time. This flexibility is necessary to test
dynamic adaptive properties of the routing exchange protocols
A variant of this scheme is proposed for implementors who do not
direct access to the IP layer in their systems. This variation
the User Datagram Protocol over IP (UDP/IP) as the subnetwork
In this memo we will call the experiment based on the IP subnet EON
an acronym for "Experimental OSI-based Network". We will call
experiment based on the UDP/IP subnet EON-UDP
It is assumed that the reader is familiar with the OSI
network layer and, in particular, with the following documents
Hagens, Hall, & Rose [Page 2]
RFC 1070 Experimental OSI Net February 1989
RFC 768
User Datagram Protocol
RFC 791
Internet Protocol
ISO 8473
Protocol for Providing the Connectionless mode Network Service
ISO DP 9542
End System to Intermediate System Routing Exchange Protocol
Use in Conjunction with the Protocol for the Provision of
Connectionless-mode Network Service (ISO 8473).
ISO TC 97/SC 6/N
Intermediate System to Intermediate System Intra-Domain
Exchange Protocol
PD TR 97/SC 6/N 9575
OSI Routing Framework
An acronym for Experimental OSI Network, a name for the
experimental OSI-based internetwork that uses the IP over
Internet as a subnetwork
EON-
A name for the proposed experimental OSI-based internetwork
uses the UDP/IP over the Internet as a subnetwork
End system as defined by OSI: an OSI network layer entity
provides the OSI network layer service to a transport layer
Hagens, Hall, & Rose [Page 3]
RFC 1070 Experimental OSI Net February 1989
The Internet Assigned Numbers Authority. Contact Joyce K
Reynolds (JKREY@ISI.EDU).
An OSI network layer entity that provides the routing
forwarding functions of the OSI connectionless network layer
OSI
OSI connectionless network layer
Network Service Data Unit
Protocol Data Unit, or packet
Network Protocol Data Unit
ISO-
An NPDU for any protocol in the OSI CLNL, including ISO 8473
(CLNP), ISO DP 9542 (ES-IS), and ISO TC 97/SC 6/N xxxx (IS-IS).
Participating
An ES or IS that is running a subset of the OSI CLNL protocols
is reachable through the application of these protocols and
agreements set forth in this memo
Core
An ES or IS that considers itself directly connected to the
subnet for the purpose of participating in EON
NSAP-
Network Service Access Point address, or an address at which
OSI network services are available to a transport entity
Hagens, Hall, & Rose [Page 4]
RFC 1070 Experimental OSI Net February 1989
SNPA-
SubNetwork Point of Attachment address, or an address at which
subnetwork service is available to the network entity
Issues to be Addressed by this
In order to make the experimental OSI internet work,
experimenters must agree upon
- how ISO-grams will be encapsulated in IP or UDP packets
- the format of NSAP-addresses to be used
- how NSAP-addresses will be mapped to SNPA-addresses
the IP subnet
- how multicasting, which is assumed by some OSI
protocols, will be satisfied,
- how topology information and host names will
disseminated
This memo contains proposals for each of these issues
Design
The goals of this memo are
- to facilitate the testing of the OSI network
protocols among different implementions
- to do this as soon as possible, exploiting
connectivity
- to do this without requiring any changes to existing
gateways
- to create a logical topology that can be
easily, for the purpose of testing the dynamic
properties of the protocols,
- to minimize the administrative requirements of
experimental internetwork
The following are not goals of this memo
Hagens, Hall, & Rose [Page 5]
RFC 1070 Experimental OSI Net February 1989
- to permit the use of arbitrary ISO-
NSAP-addresses
- to require that participants have
implementations of all of the OSI routing
before they can participate in any capacity
- to permit or encourage the use of existing IP
methods and algorithms for the routing of ISO-
among participating ESs and ISs
- to create a production-like environment accommodating
very large number of systems (ESs, ISs or both),
- to provide or to encourage IP-to-CLNP gatewaying
Encapsulating ISO-grams in IP
The entire OSI network layer PDU, whether it be an ISO 8473 PDU,
ISO DP 9542 PDU, or an IS-IS PDU, will be placed in the data
of an IP datagrams at the source. The ISO 8473 entity may
an NSDU into several NPDUs, in which case each NPDU will
encapsulated in an IP datagram. The intent is for the OSI CLNL
fragment rather than to have IP fragment, for the purpose of
the OSI CLNL. Of course, there is no guarantee that
will not occur within the IP subnet, so reassembly must be
at the IP level in the destination participating system
SNPA-addresses (Internet addresses) will be algorithmically
from the NSAP-addresses as described below. The "protocol" field
the IP datagram will take the value 80 (decimal), which has
assigned for this purpose
NSAP-Address
The OSI internetwork described here will form one routing domain
with one form of NSAP address recognized by all level 1 routers
this domain. Other address formats may be agreed upon in
editions of this memo
The address format to be used in this experiment is that specified
RFC 1069. According to RFC 1069, the low-order portion of the
Specific Part of the NSAP address may vary depending on
conventions of the particular routing domain. For the purposes
this experiment, we shall use the following address format
Hagens, Hall, & Rose [Page 6]
RFC 1070 Experimental OSI Net February 1989
Address Format for
Octet Value
-------- ------------- ----------------------------------------
1 47 Authority and Format
2,3 00, 06 International Code
4 3 Version
5,6 0 Global Area Number, see RFC 1069
7,8 RDN Routing Domain Number, assigned by
9-11 0
12,13 0 LOC-AREA, see
14,15 0
16-19 A.B.C.D Internet
20 NSAP Selector, assigned
Note: It is our desire that the address format used by EON
consistent with RFC 1069. To that end, the address
proposed by this RFC may change as future editions of RFC 1069
become available
The mapping between NSAP-addresses and SNPA-addresses (
addreses) on the proposed IP subnet is straightforward. The SNPA
address is embeded in the NSAP-address
There are several ways in which the LOC-AREA field could be used
(1) Assign local areas, administered by the Internet Assigned
Authority (IANA). The advantage of this is that it
experimentation with area routing. The disadvantage is that
will require an additional directory service to map host names
NSAP-addresses. We would like to use the existing domain
servers to derive Internet addresses from names, and we
like NSAP-addresses to be derivable from the Internet
alone
(2) Have one local area in the EON, with LOC-AREA value 0.
would eliminate the problem of name-toNSAP-address binding,
would not permit experimentation with area routing. It
not, however preclude the use of areas later, for example,
OSI directory services are widely available
(3) Make the local area a simple function of the Internet address
The advantage of this is that it would permit
with area addressing without requiring additional
services, but the areas derived would not be under the control
the experimenters and may not correspond to anything useful
meaningful for the purposes of this experiment
We believe that initially, the preferred alternative is to use
Hagens, Hall, & Rose [Page 7]
RFC 1070 Experimental OSI Net February 1989
zero-valued local areas. Later editions of this memo may
proposals for use of the local area field, when the IS-IS proposal
more mature and perhaps when OSI directory services are in use
experimenters
The value of the high-order portion of the DSP will be set
accordance with RFC 1069.
Other NSAP-Address
PDUs carrying NSAP-addresses of other formats can be routed
this domain. This is the job of the level 2 routers, described
the IS-IS document
Multicast Addresses on the IP
The ES-IS and IS-IS routing exchange protocols assume that
subnetworks support two multicast addresses: one for all ESs and
other for all ISs. While one could obviate this issue by
the IP subnet as a general topology subnetwork or as a set of point
to-point links, it is also desirable to treat the IP subnet as
broadcast subnetwork for the purpose of testing those parts of
implementation that run over broadcast subnets. A
implementor not having access to several local machines running
OSI CLNL may test the protocols over the IP subnet as if the
subnet were a broadcast subnet
The multicasting assumed by the OSI CLNL can be simulated by a
sublayer lying between the OSI CLNL and the IP subnet layer. For
purpose of this discussion, call this sublayer an SNAcP, a
Access Protocol, in OSI argot. In each system the SNAcP caches
table of the Internet addresses of systems that it considers to
reachable in one ISO 8473-hop over the IP subnet. These are
"core" systems. In this sense, the use of the cache simulates a
of links over which a system will send ISO configuration messages (
Hello, IS Hello, etc.) when it comes up. As a local matter,
table of core systems may or may not expand during the system'
lifetime, in response to configuration messages from other
systems
On the outgoing path, the SNAcP accepts an ISO-gram and a
indicating the intended use of this ISO-gram: send to a
system, to all ESs, to all ISs, or to all systems. If the
destination is a single system, the ISO-gram is sent only to
destination. Otherwise, the SNAcP makes a copy of the ISO-gram
each of the SNPA-addresses in the cache, effecting a broadcast to
participating systems. Before passing an ISO-gram to the IP
layer, the SNAcP prepends an SNAcP header to each outgoing ISO-gram
Hagens, Hall, & Rose [Page 8]
RFC 1070 Experimental OSI Net February 1989
This header will take the form
SNAcP Header
Octet Value
--------------------------------------------------------
1 01 Version
--------------------------------------------------------
2 Semantics of address
00 Not a multicast
01 All
02 All
03
--------------------------------------------------------
3,4 OSI checksum as defined in ISO 8473
The SNAcP header has three fields, a version number field,
semantics field, and a checksum field. The version number will
the value 01. The checksum field will take the two octet
(Fletcher) checksum of the SNAcP header. The checksum algorithm
described in ISO 8473.
The semantics field will take one of 4 values, indicating "all ESs",
"all ISs", "broadcast", or "not a multicast address". The value
the semantics field is determined by a parameter passed to the
by the calling OSI network entity. A participant in the
may test the OSI network layer over a set of point-to-point links
choosing not to use the multicast capabilities provided by the
on the outgoing path
On the incoming path, the SNAcP inspects the SNAcP header and
whether or not to accept the ISO-gram. If it accepts the ISO-gram
the SNAcP removes the SNAcP header and passes the ISO-gram to the
CLNL, otherwise, it discards the ISO-gram. The SNAcP will
accept ISO-grams with SNAcP headers indicating "not a
address" (value zero in the semantics field) and "broadcast" (
03). Whether an SNAcP will accept ISO-grams for either of the
multicast groups "all ESs" (value 1) and "all ISs" (value 2)
depend on local configuration information. If the system on
the SNAcP resides is configured as an end system, it will
ISO-grams destined for "all ESs" and if it is configured as
intermediate system, it will accept ISO-grams destined for "all ISs".
A participant who is testing the OSI network layer over a set
point-to-point links will accept ISO-grams according to these
as well
Consideration was given to making the SNAcP extensible by making
semantics and checksum fields variable-length parameters, in
Hagens, Hall, & Rose [Page 9]
RFC 1070 Experimental OSI Net February 1989
manner of ISO 8473. We feel that the presence of a version
provides sufficient extensibility
Errors on the IP
The IP subnet layer may receive ICMP messages and may pass
indications to the SNAcP layer as a result of having received
ICMP messages. It is assumed that in this context, the IP
will handle ICMP messages in the same way that it handles them in
other context. For example, upon receipt of an ICMP echo message
the IP subnet will respond with an ICMP echo reply, and the
need not be informed of the receipt of the ICMP echo message
Certain ICMP messages such as source quench are likely to produce
error indication to all layers using the IP subnet. The
taken by the SNAcP for these indications is purely a local matter
however the following actions are suggested
Suggested SNAcP Actions in Response
ICMP-related Error
ICMP message type Action taken by the
-----------------------------------------------------------
Destination unreachable, If the remote address is
Parameter problem, in the cache of core systems
Time exceeded addresses, mark it unusable
Inform network management
-----------------------------------------------------------
Source quench If the remote address is
in the cache of core systems
addresses, mark the
address as unusable and set
timer for a time after
the address becomes
again
Inform network management
-----------------------------------------------------------
All others Ignored by the SNAcP layer
To "inform network management" may mean to print a message on
system console, to inform a local process, to increment a counter,
write a message in a log file, or it may mean to do nothing
The effect of marking a cached address as unusable is as follows
When the SNAcP attempts to broadcast or multicast an ISO-gram
addresses in the cache that are marked as unusable are ignored.
the SNAcP attempts to send a non-multicast ISO-gram to an
cached address, the SNAcP returns an error indication to the
CLNL. In this way, when the OSI CLNL uses the SNAcP to simulate
Hagens, Hall, & Rose [Page 10]
RFC 1070 Experimental OSI Net February 1989
set of point-to-point links, it is notified when a link fails,
when the OSI CLNL uses the SNAcP to simulate a multicast subnet,
is not notified when one system on the subnet goes down
Use of UDP/IP in Lieu of
In addition to using IP directly, for testing purposes it may
useful to support the OSI CLNL over the User Datagram Protocol (UDP).
This is because some implementors do not have direct access to IP
but do have access to the UDP. For example, an implementor may
an a binary license for an operating system that provides TCP/IP
UDP/IP, but no direct access to IP. These implementors
participate in a parallel experiment, called EON-UDP, by using UDP/
as a subnetwork instead of using the IP subnet. In this case,
OSI NPDU (after fragmentation, if applicable) will be placed in
data portion of a UDP datagram. UDP port 147 (decimal) has
assigned for this purpose. These participants will place an
between UDP and ISO 8473 rather than between IP and ISO 8473. In
other respects, the EON-UDP experiment is identical to the
experiment
Of course, network layers entities using the UDP/IP subnet will
interoperate directly with network layers entities using the
subnet. The procedures proposed in this memo do not prevent
implementor from building an EON to EON-UDP gateway, however
issues related to building and routing to such a gateway are
addressed in this memo. This memo simply proposes two
parallel experiments for two groups of experimenters having
resources
The preferred method of experimentation is to use the IP subnet,
other words, EON. The EON-UDP variant is intended for use only
those who cannot participate in EON
Dissemination of Topological Information and Host
The EON experiment simulates a logical topology that is not
connected as the underlying logical topology offered by the Internet
The topology of the IP subnet is, in effect, simulated by the
layer in each of the core systems. Each of the core systems caches
list of the other core systems in the EON. When a system boots,
needs some initial list of the participating core systems. For
reason, a list of core systems will be maintained by the IANA
In addition, a list of all participating ESs will be maintained
the IANA. This list is not necessary for the functioning of the
network layer. It is a convenience to the experimenters, and
meant for use by application layer software or human users
Hagens, Hall, & Rose [Page 11]
RFC 1070 Experimental OSI Net February 1989
Two pairs of lists are kept, one for the EON and one for EON-UDP
core.EON This is a list of SNPA-addresses of those
that will be (logically) reachable via the IP
in one ISO 8473-hop from any other core system.
does not mean that systems in this file are
or ISs. They may be ESs, ISs or both. A site
participate as a core system before its address
included in this file and distributed to other
systems, but under these circumstances other core
will not know to send configuration messages (ESHs
ISHs) to the new site when coming up or rebooting.
SNPA-addresses in this file will be ASCII strings
the form A.B.C.D, no more than one per line
White space (tabs, blanks) will be optional
A and after D. A pound-sign (#) will indicate
it and everything following it on that line is a comment
For example
128.105.2.153 # bounty.cs.wisc.
core.EON-
This is the equivalent of core.EON for use
the UDP/IP subnet. The format is the same that
core.EON
hosts.EON This is a list of the ASCII host names of all
systems participating in the IP subnet experiment
one host name per line. It is not used by the
CLNL
hosts.EON-
This is a list of the ASCII host names of all
systems participating in the UDP/IP subnet experiment
one host name per line. It is meant for the use
applications. It is not used by the OSI CLNL
The files will be available from the IANA via anonymous ftp.
wishing to join the experimental OSI internet will have to have
host names and core system addresses added to the appropriate files
They may do so by sending requests to Joyce K. Reynolds at
electronic mail address
JKREY@ISI.
Hagens, Hall, & Rose [Page 12]
RFC 1070 Experimental OSI Net February 1989
Hypothetical EON
Figure 1 describes the logical links in a hypothetical topology,
which three university computer sciences departments
participating in the experiment: the University of Wisconsin (U
W), the University of Tudor (U of Tudor), and the University
Fordor (U of Fordor). The U of W has two local area networks(LANs),
128.105.4 and 128.105.2, and four systems that are acting as ESs
the experiment. Two systems are attached to both LANs. Only one
these two systems is forwarding ISO-grams, in other words, acting
an IS. The U of Tudor has only one participating system, and it
acting as an ES. The U of Fordor has two systems that
participating in the experiment, one of which is an IS only, and
other of which is acting as an ES only
The contents of the core.EON and hosts.EON files for this
are shown below
#
# core.EON for hypothetical EON
#
128.105.2.153 # IS/ES in cs.wisc.
26.5.0.73 # ES in cs.tudor.
192.5.2.1 # IS in cs.fordor.
#
# hosts.EON hypothetical EON
#
128.105.4.150 # ES in cs.wisc.
128.105.2.150 # same as above : multihomed
128.105.4.154 # ES in cs.wisc.
128.105.4.151 # ES in cs.wisc.
128.105.2.153 # IS/ES in cs.wisc.
26.5.0.73 # ES in cs.tudor.
192.5.2.2 # ES in cs.fordor.
Hagens, Hall, & Rose [Page 13]
RFC 1070 Experimental OSI Net February 1989
______U of WI (128.105)______
( )
( 128.105.4 )
( | ) _U of Tudor__
( | 128.105.2.150 ) ( )
( | 128.105.4.150 ) ( )
( |------ES-----------| ) ( ES )
( | | ) ( 26.5.0.73 )
( | | ) ( | )
( | | ) (___|_________)
( | | ) |
( | | ) -------------
( |---ES | ) _|_
( | 128.105.4.154 | ) ( )
( | | ) ( )
( | | ) ( IP )
( | |----------( subnet )
( | | ) ( )
( | | ) ( )
( | | ) (___)
( |---ES | ) |
( | 128.105.4.151 | ) -------------
( | | ) |
( | | ) _U of Fordor
( | | ) ( | )
( |---IS/ES-----------| ) ( | )
( 128.105.2.153 | ) ( IS )
( 128.105.4.153 | ) ( 192.5.2.1 )
( | ) ( | )
( | ) ( | )
( 128.105.2 ) ( ES )
( ) ( 192.5.2.2 )
(_____________________________) (_____________)
Figure 1: Hypothetical EON
The U of Fordor system 192.5.2.1 may, in addition to acting as an IS
begin acting as an ES at any time, by participating in the ES-
protocol as an ES and by beginning to serve a set of NSAPs. It
act as an ES or as an IS or as both. In fact, the U of
systems 192.5.2.1 and 192.5.2.2 could reverse roles at any time
regardless of their physical connectivity to the Internet, merely
modifying their use of the ES-IS protocol and by their serving or
serving NSAPs. Suppose that these two systems reverse roles
192.5.2.1 becomes an ES, not a core system, and 192.5.2.2 becomes
core system and an IS. Suppose further that the experimenters at
U of Fordor do not inform the IANA of the change immediately, so
Hagens, Hall, & Rose [Page 14]
RFC 1070 Experimental OSI Net February 1989
core.EON file is out-of-date for a while. The effect will be
other core systems will continue to send configuration messages
192.5.2.1, which will respond as an ES, not as an IS, and it
appear that 192.5.2.2 is not reachable from the rest of the
because the other core systems will not know to send
information to it. However, when 192.5.2.2 is booted, it will
configuration messages to all core systems informing them of
existence via the IS-IS protocol. Those core systems that are
as ISs will respond with their configuration messages, update
core system caches, thereby establishing a set of logical
between 192.5.2.2 and the rest of the core systems
Relationship of this Memo to other
RFCs 1006 and 983
ISO Transport Services on top of the TCP. Whereas RFCs 1006
983 offer a means of running the OSI session layer protocol
higher OSI layers over TCP/IP, this memo provides a means
running the OSI network and transport layers on an
internetwork
RFC 1069
Guidelines for the use of Internet-IP addresses in the
Connectionless-Mode Network Protocol. RFC 1069 suggests a
to use the existing Internet routing and addressing in a
that forwards ISO connectionless network layer protocol datagrams
In contrast, this memo suggests a method to use the ISO
and addressing in a gateway that forwards ISO
network layer protocol datagrams
RFC 982
ANSI Working Document X3S3.3/85-258. This is a set of
for specifying the structure of the DSP part of an ISO address
The addresses described in this memo meet the guidelines set
in RFC 982.
Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet
for Transmission on Ethernet Hardware", RFC 826, MIT,
1982.
Finlayson, R., T. Mann, J. Mogul, and M. Theimer, "A
Address Resolution Protocol", RFC 903, Stanford, June 1984.
Hagens, Hall, & Rose [Page 15]
RFC 1070 Experimental OSI Net February 1989
Postel, J., "Internet Protocol - DARPA Internet Program
Specification", RFC 791, DARPA, September 1981.
Postel, J., "Internet Control Message Protocol - DARPA
Program Protocol Specification", RFC 792, ISI, September 1981.
Postel, J., "User Datagram Protocol", RFC 768, ISI, August 1980.
ISO, "Protocol For Providing the Connectionless Mode
Service", (ISO 8473), March 1986. (This is also published as
994.)
ISO, "End System to Intermediate System Routing Exchange
for Use in Conjunction with the Protocol for the Provision of
Connectionless-mode Network Service (ISO 8473)", (ISO DP 9542).
(This is also published as RFC 995.)
ISO, "Intermediate System to Intermediate System Intra-
Routing Exchange Protocol", (ISO TC 97/SC 6/N xxxx).
OSI, "OSI Routing Framework", (PD TR 97/SC 6/N 9575).
Hagens, Hall, & Rose [Page 16]
RFC 1070 Experimental OSI Net February 1989
Authors'
Robert A.
Computer Sciences
University of Wisconsin -
1210 West Dayton
Madison, WI 53706
608/ 262-1017
EMail: hagens@cs.wisc.
Nancy E.
Computer Sciences
University of Wisconsin -
1210 West Dayton
Madison, WI 53706
608/ 262-5945
EMail: nhall@cs.wisc.
Marshall T.
The Wollongong
San Antonio Blvd
Palo Alto,
415/ 962-7100
Email: mrose@twg.
Comments and
Please direct comments, suggestions, and indications of desire
participate to the authors
Hagens, Hall, & Rose [Page 17]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
